Re: Review Request: Much less flickering when there is no backing store
On 2009-03-31 17:49:41, Aaron Seigo wrote: perhaps Qt::HANDLE QPixmap::x11PictureHandle() const would work for comparing the pixmaps? In each pass, the pixmaps are created newly using deep copies, by QPixmap::copyRect(..), so I fear the identity is different every time(I already checked QPixmap::cacheKey()). Ah yeah, the basic pixmap they are copied from is also different every time. :) My hope was that there might be some XRender function or something like that, but I haven't found any. - David --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/488/#review766 --- On 2009-03-31 17:11:55, David Nolden wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/488/ --- (Updated 2009-03-31 17:11:55) Review request for Plasma. Summary --- Remember the background image used for the tray-icon, and do not update it if it has not changed. The following XClearArea call leads to a very annoying flicker when the backing-store is disabled, and to the user, it happens at totally random occasions. Unfortunately this can only be implemented cheaply for the raster engine, since there does not seem to be an efficient way to compare QPixmap's. Diffs - trunk/KDE/kdebase/workspace/plasma/applets/systemtray/protocols/fdo/x11embedcontainer.cpp 940781 Diff: http://reviewboard.kde.org/r/488/diff Testing --- Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: April 7 soft feature freeze
On Wednesday 01 April 2009, Aaron J. Seigo wrote: hi all just a quick reminding there April 7 is the soft feature freeze for 4.3. that means that a feature must at least be on the feature plan, and best is if they are at least started in svn. so i have until hadr freeze to move the systray in support, rght? :) a thing that really wanted and probably will be postponed again is the panel sadow, uff :/ don't get caught out! :) it would be great to see some of the plugins sitting in kdereview move out. oh, and should move 2 plasmoids -in- kdereview, now that i think about it :p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray benchmarks
On Wednesday 01 April 2009, Rob Scheepmaker wrote: On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. here we go: png: 8.97 8.96 8.92 8.76 9 8.86 9.03 9.07 8.77 9.19 average 8.95 raw 2.868 2.698 2.821 2.915 2.877 2.816 2.819 2.685 2.790 2.783 average 2.807 in this case the difference is so embrassing that i wonder if there is something wrong but yeah, it seems to justify using raw :p Cheers, Marco Martin Regards, Rob ___ 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: Systemtray benchmarks
On Wednesday 01 April 2009 11:09:52 Marco Martin wrote: On Wednesday 01 April 2009, Rob Scheepmaker wrote: On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. here we go: png: 8.97 8.96 8.92 8.76 9 8.86 9.03 9.07 8.77 9.19 average 8.95 raw 2.868 2.698 2.821 2.915 2.877 2.816 2.819 2.685 2.790 2.783 average 2.807 in this case the difference is so embrassing that i wonder if there is something wrong but yeah, it seems to justify using raw :p Ok, thanks for running this benchmark: indeed dbus seems a lot faster then I expected it to be. I'd better also move the notification's image data to raw format. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Question about idea:D-Bus Interface for plasma-desktop
hi, all after digging around both the techbase.kde.org and svn trunk, It seems Containment is playing with Plasma::Applet, and widget is a top level visualization, as we are talking about the interfaces,APIs stuff, I think it's better to make it clear and more specifically. Maybe it's better with Plasma::Applet than widget in the ideas page? http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_D-Bus_Interface Cheers, Li Dongyang ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
On Wednesday 01 April 2009 13:56:43 Thomas Schildknecht wrote: I'm planning to make a desktop containment with a feature that I've seen in XFCE (well, I think) : adding a margin at the edges of the screen so that windows can't cover this area. I think it's useful because with a big margin at the bottom, I can put a floating macOsX-like dock or some other widgets. Moreover, when someone use a very high resolution for his display, maximizing windows is not very usefull because the maximized window is really too big (and it just looks better with a margin around the window :) ). Finally, I'm a big fan of the switch desktop with scrollwheel and with this feature, I can always have some visible area of the desktop. You can also mousewheel on the pager, just in case you didn't know that. I'm not very familiar with the internals of Plasma, so before I start digging into the code, can someone tell me if this is feasible with a desktop containment (for example, cloning the default desktop and adding this feature) ? What you're talking about is I think essentially a strut. -- 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: Adding a margin around the desktop containment
What you're talking about is I think essentially a strut. A strut ? What are you talking about ? And do you think what I said is doable ? Thanks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
On Wednesday 01 April 2009 14:41:21 Thomas Schildknecht wrote: What you're talking about is I think essentially a strut. A strut ? What are you talking about ? And do you think what I said is doable ? Thanks It's most certainly doable. Take a look at http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/classKWindowSystem.html With setStrut or setExtendedStruts, you can set struts. Struts are basically area's of which kwin is made aware that windows aren't supposed to cover them when maximizing the window. Basically you could implement your own containment type which has config options for margins and which uses KWindowSystem to set the struts depending on those margins. Good luck! :) Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The option Date for plasmoid Notes.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/415/ --- (Updated 2009-04-01 06:47:14.037971) Review request for Plasma. Changes --- some modification . Summary --- This patch adds to the plasmoid notes the possibility to show the (updated) date when a note is created(modified) . If you notice any problems with this new option just tell me Diffs (updated) - trunk/KDE/kdeplasma-addons/applets/notes/config.ui 947868 trunk/KDE/kdeplasma-addons/applets/notes/notes.h 947868 trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 947868 Diff: http://reviewboard.kde.org/r/415/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/415/s/87/ http://reviewboard.kde.org/r/415/s/88/ Thanks, Sylvain ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add support for KUrl config values in javascript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/496/ --- Review request for Plasma. Summary --- Add support for KUrl config values. Needed e.g. if ui file has KUrlRequester. Diffs - /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/appletinterface.h 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/appletinterface.cpp 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.h 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.cpp 947782 Diff: http://reviewboard.kde.org/r/496/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
2009/4/1 Thomas Schildknecht danakil@gmail.com Hello :) I'm planning to make a desktop containment with a feature that I've seen in XFCE (well, I think) : adding a margin at the edges of Well, rather than writing a new containment you can just provide a patch for the existing one that allows the user whether to set margins or not.. But those are just my 2 cents :) Good luck with it ;-) the screen so that windows can't cover this area. I think it's useful because with a big margin at the bottom, I can put a floating macOsX-like dock or some other widgets. Moreover, when someone use a very high resolution for his display, maximizing windows is not very usefull because the maximized window is really too big (and it just looks better with a margin around the window :) ). Finally, I'm a big fan of the switch desktop with scrollwheel and with this feature, I can always have some visible area of the desktop. I'm not very familiar with the internals of Plasma, so before I start digging into the code, can someone tell me if this is feasible with a desktop containment (for example, cloning the default desktop and adding this feature) ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Question about idea:D-Bus Interface for plasma-desktop
On Wednesday 01 April 2009, Li Dongyang wrote: after digging around both the techbase.kde.org and svn trunk, It seems Containment is playing with Plasma::Applet, and widget is a top level visualization, as we are talking about the interfaces,APIs stuff, I think it's better to make it clear and more specifically. Maybe it's better with Plasma::Applet than widget in the ideas page? yes, it would be an interface to Plasma::Applet objects; when talking or writing about those things that we put on the desktop, panels, etc we tend to call the widgets as a generic term. but in this case, it is indeed specifically about the Plasma::Applet class. -- 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: April 7 soft feature freeze
On Wednesday 01 April 2009, Marco Martin wrote: On Wednesday 01 April 2009, Aaron J. Seigo wrote: hi all just a quick reminding there April 7 is the soft feature freeze for 4.3. that means that a feature must at least be on the feature plan, and best is if they are at least started in svn. so i have until hadr freeze to move the systray in support, rght? :) yes :) -- 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: Review Request: Add keyboard navigation to plasma applet Folder View
On 2009-03-20 14:07:32, Fredrik Höglund wrote:
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp, line 1208
http://reviewboard.kde.org/r/368/diff/2/?file=3392#file3392line1208
A problem with the way this function is implemented is that it assumes
that the view is always sorted and that the icons always flow from left to
right.
When the user has rearranged the icons (m_layoutBroken is true), you
have to assume that the icons are no longer arranged in a grid and that the
visual order no longer matches the order in the model.
When this is the case, and the user has pressed the up key for example,
you have to iterate over all the icons and find the one that is closest to
the current icon while still being above it.
wrote:
you have to iterate over all the icons. I'm working on this by
iterating all icons and finding the nearest one to the current selection
according to the key pressed, but the code is getting really complex in terms
of calculations. I was wondering if there is any other way of doing this? If
anyone has an idea, please let me know. Till then I'm working on it.
wrote:
I would do something like this (the example is for the up key only):
QModelIndex nextIndex = QModelIndex();
QPoint currentPos = visualRect(currentIndex).center();
int lastDistance = 0;
for (int i = 0; i m_validRows; i++) {
const QModelIndex index = m_model-index(i, 0);
const QPoint pos = visualRect(index).center();
if (pos.y() currentPos.y()) {
int distance = (pos - currentPos).manhattanLength();
if (distance lastDistance || !currentIndex.isValid()) {
nextIndex = index;
lastDistance = distance;
}
}
}
If nextIndex is valid when you get here, it's the index you should move
to.
If it isn't valid there are no icons above the current icon.
Thanks for working on this feature :)
Ok, thanks for the help, that was less complex then mine ;) Its almost done,
just a few minor issues remaining.
But, I'm unable to understand why you're using `!currentIndex.isValid()` in if
(distance lastDistance || !currentIndex.isValid()) ?
Why do we need to validate the currentIndex ?
- Shantanu
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/#review541
---
On 2009-03-20 22:14:51, Shantanu Tushar Jha wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/
---
(Updated 2009-03-20 22:14:51)
Review request for Plasma.
Summary
---
This partly addresses the above bug, adding keyboard navigation and launch
using Enter key.
Please report if the code is too complex, I've tried my best to keep it to
the point.
This addresses bug 187241.
https://bugs.kde.org/show_bug.cgi?id=187241
Diffs
-
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 942106
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 942106
Diff: http://reviewboard.kde.org/r/368/diff
Testing
---
Tested on latest SVN build. Navigation and launch work fine. The problem is
with movement of the scrollbar with the keyboard focus, the scrollbar refuses
to go to minimum value when m_scrollBar-setValue( m_scrollBar-minimum() );
is used. What am I doing wrong?
Thanks,
Shantanu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
On Wed, Apr 1, 2009 at 1:56 PM, Thomas Schildknecht danakil@gmail.com wrote: Hello :) I'm planning to make a desktop containment with a feature that I've seen in XFCE (well, I think) : adding a margin at the edges of the screen so that windows can't cover this area. I think it's useful because with a big margin at the bottom, I can put a floating macOsX-like dock or some other widgets. Moreover, when someone use a very high resolution for his display, maximizing windows is not very usefull because the maximized window is really too big (and it just looks better with a margin around the window :) ). Finally, I'm a big fan of the switch desktop with scrollwheel and with this feature, I can always have some visible area of the desktop. hmm, what it woiuld have more than simply a panel not 100% wide? I'm not very familiar with the internals of Plasma, so before I start digging into the code, can someone tell me if this is feasible with a desktop containment (for example, cloning the default desktop and adding this feature) ? KWindowSystem::setExtendedStrut() i'm not too sure containment is the right place to go but yeah, quite easy ___ 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: Add support for KUrl config values in javascript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/496/#review777 --- Ship it! couple of comments, but generally good ... /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.h http://reviewboard.kde.org/r/496/#comment461 maybe a good opportunity to get rid of the '2' in the name and just make it variantToScriptValue everywhere. /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.cpp http://reviewboard.kde.org/r/496/#comment462 how about QUrl too? /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.cpp http://reviewboard.kde.org/r/496/#comment463 this could just become a (static?) member of the class instead of having a member method that calls a file global function? - Aaron On 2009-04-01 06:51:44, Petri Damstén wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/496/ --- (Updated 2009-04-01 06:51:44) Review request for Plasma. Summary --- Add support for KUrl config values. Needed e.g. if ui file has KUrlRequester. Diffs - /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/appletinterface.h 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/appletinterface.cpp 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.h 947782 /trunk/KDE/kdebase/workspace/plasma/scriptengines/javascript/simplejavascriptapplet.cpp 947782 Diff: http://reviewboard.kde.org/r/496/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
GSoC: Educational layout (revised)
Hi, I am trying to take part of GSoC with Educational layout project. I have put my revised proposal here: http://v6sa.itcollege.ee/GSoC/2009/educational_layout.html -- Lauri Võsandi tel: +372 53329412 (Estonia) e-mail: lauri.vosa...@gmail.com university: IT College job: Arvuti Traumapunkt OÜ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
Well, rather than writing a new containment you can just provide a patch for the existing one that allows the user whether to set margins or not.. it's a very specific feature so I don't think many people will be interested :) anyways, I quickly added some struts to the desktop; it basically works but there is a problem : when a popup menu like Kickoff, the menu from grouped tasks in the taskbar or the panel toolbar is showed, it respect the struts and is not attached to the panel anymore... so it don't look like an easily solvable problem (for me at least) oh, and the window decoration is not painted when maximized so it's not very cool to have a borderless window in the middle of the screen... On 4/1/09, Alessandro Diaferia alediafe...@gmail.com wrote: 2009/4/1 Thomas Schildknecht danakil@gmail.com Hello :) I'm planning to make a desktop containment with a feature that I've seen in XFCE (well, I think) : adding a margin at the edges of Well, rather than writing a new containment you can just provide a patch for the existing one that allows the user whether to set margins or not.. But those are just my 2 cents :) Good luck with it ;-) the screen so that windows can't cover this area. I think it's useful because with a big margin at the bottom, I can put a floating macOsX-like dock or some other widgets. Moreover, when someone use a very high resolution for his display, maximizing windows is not very usefull because the maximized window is really too big (and it just looks better with a margin around the window :) ). Finally, I'm a big fan of the switch desktop with scrollwheel and with this feature, I can always have some visible area of the desktop. I'm not very familiar with the internals of Plasma, so before I start digging into the code, can someone tell me if this is feasible with a desktop containment (for example, cloning the default desktop and adding this feature) ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a margin around the desktop containment
On Wednesday 01 April 2009, Thomas Schildknecht wrote: Well, rather than writing a new containment you can just provide a patch for the existing one that allows the user whether to set margins or not.. it's a very specific feature so I don't think many people will be interested :) anyways, I quickly added some struts to the desktop; it basically works but there is a problem : when a popup menu like Kickoff, the menu from grouped tasks in the taskbar or the panel toolbar is showed, it respect the struts and is not attached to the panel anymore... that would be kwin being helpful and keeping all windows inside the struts. an ignore struts window hint would be nice in this case, and we could just set that on all of plasma's popups. oh, and the window decoration is not painted when maximized so it's not very cool to have a borderless window in the middle of the screen... i wonder if there would be a way to work around that in kwin .. hmm.. -- 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: Adding a margin around the desktop containment
anyways, I quickly added some struts to the desktop; it basically works but there is a problem : when a popup menu like Kickoff, the menu from grouped tasks in the taskbar or the panel toolbar is showed, it respect the struts and is not attached to the panel anymore... that would be kwin being helpful and keeping all windows inside the struts. an ignore struts window hint would be nice in this case, and we could just set that on all of plasma's popups. that reminds me, struts and autohide panels don't always get along... when I plug in a usb drive or something, the device notifier pops up half an inch below the top of my screen, even though I never unhid the panel. why's it respecting a strut that doesn't exist? and when I have grouped tasks and move my mouse into a group, the panel hides and leaves me with this floating tasklist... well, that one's really just a taskbar/panel bug, I guess. I've seen funny things with regular panels and the dashboard, too - ideally we should ignore all struts when we call up the dashboard. -- 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: GSoC: Educational layout (revised)
On April 1, 2009 12:24:09 lauri wrote: Hi, I am trying to take part of GSoC with Educational layout project. I have put my revised proposal here: http://v6sa.itcollege.ee/GSoC/2009/educational_layout.html you've submitted it to the gsoc site too, right? -- 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: GSoC: Educational layout (revised)
On Wednesday 01 April 2009 18:02:23 Chani wrote: you've submitted it to the gsoc site too, right? Yes, he had.. =) He's just looking for more feedback.. Cheers! -- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://labs.morpheuz.eng.br/blog/ GPG: 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: [GSoC] plasma-mid proposal
Hi Arthur! (how weird is to write an email to someone with almost the same name! =P) On Wednesday 01 April 2009 17:50:47 Arthur Renato Mello wrote: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/arthurmell o/t123861872333 Nice that you sent a proposal =). Just read it and what most concerns me is that the mockups looks too much like Maemo itself, and the last years prove that Maemo's UI was a mess for smaller devices. Having a panel that shows some kind of bubbles for menus doesn't make use of the whole available space. It would be good something like what Emmanuel proposed that use Plasma's concept of activities and also uses the available space with plasmoids, making the user's life easier ;) Cheers! -- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://labs.morpheuz.eng.br/blog/ GPG: 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: Adding a margin around the desktop containment
On Wednesday 01 April 2009, Chani wrote: anyways, I quickly added some struts to the desktop; it basically works but there is a problem : when a popup menu like Kickoff, the menu from grouped tasks in the taskbar or the panel toolbar is showed, it respect the struts and is not attached to the panel anymore... that would be kwin being helpful and keeping all windows inside the struts. an ignore struts window hint would be nice in this case, and we could just set that on all of plasma's popups. that reminds me, struts and autohide panels don't always get along... when I plug in a usb drive or something, the device notifier pops up half an inch below the top of my screen, even though I never unhid the panel. why's it respecting a strut that doesn't exist? it's not actually the strut, but popupPosition that would be wrong here. hiding panels never reserve struts at all. and when I have grouped tasks and move my mouse into a group, the panel hides and leaves me with this floating tasklist... well, that one's really just a taskbar/panel bug, I guess. we have a way to detect popups in PanelView to inhibit hiding, but the API described would probably make it a lot easier for the tasks widget to get it right, too. I've seen funny things with regular panels and the dashboard, too - ideally we should ignore all struts when we call up the dashboard. you mean that you can't drag widgets into the space where panels are? that would be because the DefaultDesktop layout manager takes those into consideration ... which makes sense, unless you have a dashboard-specific containment in which case it probably doesn't. hm.. maybe we should have a Dashboard containment? it wouldn't support wallpapers (doesn't need to ... if you don't have composite, you can just use the follows-desktop mode) and wouldn't do anything funky with widgets to keep them laid out. that way we could put those off with panels somewhere and let people select one of them to use as their dashboard (along with show desktop contents)? thoughts? -- 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: Adding a margin around the desktop containment
anyways, I quickly added some struts to the desktop; it basically works but there is a problem : when a popup menu like Kickoff, the menu from grouped tasks in the taskbar or the panel toolbar is showed, it respect the struts and is not attached to the panel anymore... that would be kwin being helpful and keeping all windows inside the struts. an ignore struts window hint would be nice in this case, and we could just set that on all of plasma's popups. that reminds me, struts and autohide panels don't always get along... when I plug in a usb drive or something, the device notifier pops up half an inch below the top of my screen, even though I never unhid the panel. why's it respecting a strut that doesn't exist? and when I have grouped tasks and move my mouse into a group, the panel hides and leaves me with this floating tasklist... well, that one's really just a taskbar/panel bug, I guess. I've seen funny things with regular panels and the dashboard, too - ideally we should ignore all struts when we call up the dashboard. -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma on MID, take 2
Hi, sorry for not sending news int he last few day, I am not dead, just in exam week. I don't have much time to do anything on the proposal until Saturday (too late for update). But about the way of selecting favorite application, I did sat down and think about it. I think the best way, for now, is the most simple one: most used apps and user selected favorite. It is not perfect, but it is the best simple way of doing it and we have to admit it, even compared with the most crazy algorithm, it win. But I also found a way (I think) of making the geolocaion/wifi/bluetooth concept fit into less than 1mB of data and few calculation. By using profile, linking them and merging them, I think I can make something that can produce 15 profiles and associate them with area or wifi spot with some level of accuracy. It use basically use base GPS coordinate and do a triangle to (x, y) mark a location. Like that I can save a lot of space by using smaller length binary integer. The system would keep 16 base coordinate and would drop less frequently used one if it need place. A new one is created when the user go over the maximum range of other points. The triangle would use 100 for 1 (in meter) so an area would be 100x100 meter, solving the area size problem. The integer would be formatted like that: 10bit for x and 10 for y, making a 100km range for each base point. So the whole goelocation system can fit in 24bit (4+10+10). The last base coordinate (16) will be dedicated to wifi spot. The last 20 bit will contain, in that case, an hashed version on the spot name, or a part of the mac address. 20 bit is too few to store any accurate information, but there is probably a way to have 90%+ accuracy based on probability, this is not yet clear how. After that, it will build an application index. The index will link an application with an integer (on 8bit (0-256)). Each applications would be followed by a use counter in 8 bit. Time will be in cut in 20 minute tranches in a 6 bit in length integer. (0 = 0:00, 1 = 0:20, 3 = 1:00) A typical entry will look like: basepoint;x;y;time;app3(count);app3(count);app3(count);endFlag 16;wifi;time;app3(count);app3(count);app3(count);endFlag Both of these entry will fit in 74bit, it can be more or less depending on the number of applications. This would grow quickly and become quite big. But grouping/merging those profile is easy. When the device is charging, a grouping and merging task can be lanched. Merging will take 2 entry with the same / close location and same / close time and will fusion both app list into 1 new entry and will drop the old 1. Grouping would take many entry with similar application list and link location and time. The file would be splited like that: section1: app index section2: location index (with a counter on 6 bit (not present the normal entry)) section3: time list (many time 6 bit followed with an endFlag) section4: profile with a 8bit index and a unix time integer to keep the last time the profile was used. section5: normal/unsorted/new entry Each location or time would be linked to 1 profile (making possible to have many time the same location/time, but it is a problem). Grouping will take a bunch of simillar profile, merge the application part and send each location and time to section2 and 3. The new counter introduced in section 2 will allow to drop rarely used location. The unix time in section 4 will allow to drop rarely use profile. Fanally, section5 entry with low use count would be dropped too. The droping would be made every month. It will drop newer entry, but it should not affect result that much. Those montly cleaning and merge/gouping (every time the device is charging) should keep the file small. I think it solve the data problem. It may not be perfect yet, but it is the best solution I found. I don't plan to make this algorithm this summer. My current proposal will require a lot of time in his current form, I don't want to add too much stuff. This algorithm is something that can be done later. After all, proposing few application may be the most complex part, but it is not the most important. Having an usable, solid and flexible way of building netbook and MID interfaces with plasma is really my goal for this years. Anything I can do (that does not require too much time, I have important exam until friday) to improve my proposal and have higher chances of seeing it accepted? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
