Re: mouse actions
On Friday 29 January 2010, Hugo Pereira Da Costa wrote: Hi, for the record, I just committed and backported a patch to the oxygen style that fixes the background issue found in kde4.4 rc1 and rc2 for (notably) the mouse-actions configuration dialog. A screenshot of fixed mouse action dialog can be found at: you rock man :) http://www.flickr.com/photos/42123...@n03/4313169406/sizes/o/ (yes I'm using quadros as a background and I love it ;-)) eheh, agree :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: mouse actions
On Friday, 29 de January de 2010 10:04:39 Marco Martin wrote: On Friday 29 January 2010, Hugo Pereira Da Costa wrote: Hi, for the record, I just committed and backported a patch to the oxygen style that fixes the background issue found in kde4.4 rc1 and rc2 for (notably) the mouse-actions configuration dialog. A screenshot of fixed mouse action dialog can be found at: you rock man :) http://www.flickr.com/photos/42123...@n03/4313169406/sizes/o/ (yes I'm using quadros as a background and I love it ;-)) eheh, agree :) Cheers, Marco Martin with so many rocking people we could do a freaking great rock group :D -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Support for the plasma:/ protocol in urls from emails/web pages and the network:/ kioslave
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1515/ --- (Updated 2010-01-29 16:23:40.126653) Review request for Plasma. Changes --- Patch updated with the .protocol file now in the subdirectory data. No other changes. Summary --- Hi! With commit #1019443 to kdebase/runtime/kioslave/network (done today) I added a new entry for Plasma service to the DNSSD (zeroconf) backend for the network:/ kioslave, which means that network:/ should now show a nice Plasma icon for such services and have a link plasma:/hostname:port/name connected to the entry. (Beware, you need to restart kded after updating your install, as the kioslave is feeded by a kded module, which has the data in the binary (yes, TODO :) )! Perhaps you even have to load the module manually, the automatic load is reported to sometimes fail: qdbus org.kde.kded /kded loadModule networkwatcher). Now, the listing in network:/ is one thing, one also wants to deal with the service item in Konqueror, e.g. click on it or drag'n'drop it to the Plasma workspace. The same happens if the plasma:/ url is used in web pages or emails (Son, here you can connect to my Dinner-is-ready plasmoid, Yours, Mum), or isn't this supposed to be done? With KIO there is the need of a .protocol file which describes what the plasma:/ protocol is about (see patch for prototype). AFAIK for such protocols not starting a kioslave, but a helper program (helper=true), that one needs to be defined here in the exec= line. So what would the helper program be for plasma:/ urls? For Drag'nDrops this entry is ignored, BTW, and just the url passed. Diffs (updated) - trunk/KDE/kdelibs/plasma/CMakeLists.txt 1080290 trunk/KDE/kdelibs/plasma/data/plasma.protocol PRE-CREATION Diff: http://reviewboard.kde.org/r/1515/diff Testing --- Thanks, Friedrich W. H. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix segmentation fault at plasma_applet_animation_example
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2738/#review3964
---
a good step in the right direction, but the leak is still there and the smart
pointer isn't actually being used :) it's all simple to fix, though. with the
changes noted below made, this can then be committed to svn (and it should be
backported as well)
trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp
http://reviewboard.kde.org/r/2738/#comment3350
should be:
delete m_wLayout.data();
trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp
http://reviewboard.kde.org/r/2738/#comment3347
should be:
if (targetWidget() backWidget layout)
trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp
http://reviewboard.kde.org/r/2738/#comment3348
probably don't need m_backWidget.data() here, just use backWidget.
m_backWidget.data() makes me think we need to check it's value, which we don't
:)
trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp
http://reviewboard.kde.org/r/2738/#comment3349
needs:
if (!layout) {
return;
}
- Aaron
On 2010-01-28 15:39:43, loureiro wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2738/
---
(Updated 2010-01-28 15:39:43)
Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson
Cavalcanti.
Summary
---
This is a small patch that fix a segmentation fault at
plasma_applet_animation_example when we close the window.
Basically I remove the delete sentence at the RotationStackedAnimation's
destruct, I made it because I think when we create a QGraphicsLinearLayout
passing a widget that widget will be the owner and responsible to delete it
as well its children elements and running the example under valgrind I don't
get leaks.
Diffs
-
trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1080090
trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1080090
trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1080090
trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1080090
Diff: http://reviewboard.kde.org/r/2738/diff
Testing
---
Thanks,
loureiro
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Calendar data engine widget future plans
Hi guys, I'm currently revising the KHolidays library to be more useful, in particular: * Return a date range, not just a single date * Support non-Gregorian calendars (Islamic Jewish holidays, etc) * Add holiday type (Public, School, Financial, Religious, Cultural, etc) * Split holiday region files by type / sub-region / etc, i.e. allow separate selection of national, provincial and religious holiday files, etc * Add file metadata for region, language, name, etc. * Proper translation of holiday region name (but not holiday names themselves) I'm planning to use the Plasma Calendar as a test client for these changes and so want to add the following: * Support multiple holidays on each day * Support multiple holiday regions at once * Choose which holiday region(s) to highlight as days off * Tool-tip on hover over day showing any holidays Of course, this is it is also a start on how to display PIM data from Akonadi (if not yet the two-way integration). I'm not sure if anyone is planning to work on that yet, but decisions on how to display holidays will affect pim and so need to be thought about together. Some points that will need input from you and the usability guys: * How do we highlight holidays, just stick to the current halo, or support multiple methods such as halo colour, day number colour, day number bold/italic, and cell background colour/shade. * Do we provide users the option of choosing the highlight method for each holiday type, or not to highlight some types? Or do we impose 'sensible' options? * How do we highlight multiple holidays and types on the same day cell? Do we rank holiday types so we show only a single highlight for each day, apply ranking at the highlight method level, or try show all types at once? (See bug 46262 for some user suggestions on PIM display in general). Has anyone used other calendar applets that do this well that we can learn from? * How to show Weekends (shading of cell or day header?) and Day of Religious Observance (red day number? possibly do same for all religious holidays?). * In configuration, for selecting multiple holiday regions I was thinking to have all the available regions listed like the timezones are, but with two tick-boxes, one for show on calendar and another for show as days-off. As always we need to balance features with ease-of-use and not end up with a visual mess. Just on pim/akonadi integration, I think the obvious interaction would be double-click on a day opens KOrganizer on that day, right-click on a day puts options in the menu for add/edit pim 'stuff' for that day. That's not my immediate priority, but we should think about it in general terms to see if it would clash with the holidays handling. Thoughts? John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix segmentation fault at plasma_applet_animation_example
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/ --- (Updated 2010-01-29 19:32:53.244002) Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson Cavalcanti. Changes --- I updated the diff now I made the changes suggest by aseigo. Summary --- This is a small patch that fix a segmentation fault at plasma_applet_animation_example when we close the window. Basically I remove the delete sentence at the RotationStackedAnimation's destruct, I made it because I think when we create a QGraphicsLinearLayout passing a widget that widget will be the owner and responsible to delete it as well its children elements and running the example under valgrind I don't get leaks. Diffs (updated) - trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1082016 trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1082016 Diff: http://reviewboard.kde.org/r/2738/diff Testing --- Thanks, loureiro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix segmentation fault at plasma_applet_animation_example
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/#review3968 --- Ship it! Ok .. if you implemented all Aaron's requests, you can commit - igorto On 2010-01-29 19:32:53, loureiro wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/ --- (Updated 2010-01-29 19:32:53) Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson Cavalcanti. Summary --- This is a small patch that fix a segmentation fault at plasma_applet_animation_example when we close the window. Basically I remove the delete sentence at the RotationStackedAnimation's destruct, I made it because I think when we create a QGraphicsLinearLayout passing a widget that widget will be the owner and responsible to delete it as well its children elements and running the example under valgrind I don't get leaks. Diffs - trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1082016 trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1082016 Diff: http://reviewboard.kde.org/r/2738/diff Testing --- Thanks, loureiro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma.WebView
Could someone give me an example of using Plasma.WebView especially if i want to open file on my hard disk? Please ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: mouse actions
On January 29, 2010 02:04:39 Marco Martin wrote: On Friday 29 January 2010, Hugo Pereira Da Costa wrote: Hi, for the record, I just committed and backported a patch to the oxygen style that fixes the background issue found in kde4.4 rc1 and rc2 for (notably) the mouse-actions configuration dialog. A screenshot of fixed mouse action dialog can be found at: you rock man :) +1 :) -- 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: Plasma Calendar data engine widget future plans
On January 29, 2010, John Layt wrote: I'm currently revising the KHolidays library to be more useful, in particular: sounds like a really great list of features! I'm planning to use the Plasma Calendar as a test client for these changes and so want to add the following: * Support multiple holidays on each day i think we already do internally, but we don't visually display this day has more than one holiday * Support multiple holiday regions at once * Choose which holiday region(s) to highlight as days off sounds good * Tool-tip on hover over day showing any holidays right now that's done with a click. it certainly has its draw backs, and a tooltip sounds like it might work, my only concern is covering the rest of the calendar which could be annoying. Of course, this is it is also a start on how to display PIM data from Akonadi (if not yet the two-way integration). I'm not sure if anyone is planning to work on that yet, but decisions on how to display holidays will affect pim and so need to be thought about together. i think the kde pim people likely have more experience in these matters than we do, and so it would be good to bring them into the discussion early on as well. best would be if the plasma calendar and what we see in korganizer harmonizes visually. i think the plasma calendar should remain simple and provide more of an overview than korganizer does, but they should work together visually as well as functionally imo. * Do we provide users the option of choosing the highlight method for each holiday type, or not to highlight some types? if we do, this should be desktop-wide imho. * How do we highlight holidays, just stick to the current halo, or support multiple methods such as halo colour, day number colour, day number bold/italic, and cell background colour/shade. * How do we highlight multiple holidays and types on the same day cell? Do we rank holiday types so we show only a single highlight for each day, apply ranking at the highlight method level, or try show all types at once? (See bug 46262 for some user suggestions on PIM display in general). Has anyone used other calendar applets that do this well that we can learn from? these two are related. we really want to be able to show, simultaneously: * this day has holidays * this day has appointments * this day is a non-working day i don't think we can show much information at all in the plasma calendar without making it very large. we can, however, alter the background and the halo around the days. this sounds like a job for visual design: how to communicate three piece of boolean information in a small space using color and shape only. i don't think we'll have the ability to show all the information (1 holiday, 3 appointements, etc.) in one small square, though. maybe showing horizontal bars across the day itself showing when appointments take place would be best? in fact, with that approach we could show how many appointments one has in which blocks of time. holidays could be shown with a different background treatment (e.g. color) and days off could simply not have bold text used for the date? another possible idea: when you hover over an entry it could expand and show a bit more information in it, such as the number of each kind or activity. when clicking on a day, it could replace the calendar view with more information and some helpful buttons: calendar (return to the calendar view), next and previous days, open in $CALENDAR_APP when the calendar is hidden, it could be reset to the month view. * How to show Weekends (shading of cell or day header?) and Day of Religious Observance (red day number? possibly do same for all religious holidays?). this is one for the visual designers, i think. * In configuration, for selecting multiple holiday regions I was thinking to have all the available regions listed like the timezones are, but with two tick-boxes, one for show on calendar and another for show as days-off. sounds good to my ears ... -- 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.WebView
On January 29, 2010, Sinkov Vladimir wrote: Could someone give me an example of using Plasma.WebView especially if i want to open file on my hard disk? Please in c++: Plasma::WebView *webview = new Plasma::WebView(this); webview-setUrl(pathToFile); then add it to your layout somewhere. note that setUrl takes a KUrl, but i believe QStrings get converted to a KUrl automatically in this case in javascript: var webview = new WebView webview.url = Url(pathToFile) then add it to your layout somewhere. the python/ruby versions probably look nearly identical to the c++ one. -- 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: Review Request: Fix segmentation fault at plasma_applet_animation_example
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/#review3970 --- will fix this in svn, but good to keep in mind for future :) trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp http://reviewboard.kde.org/r/2738/#comment3352 btw, why not just: m_wLayout = new StackedLayout; m_sLayout is the wrong naming in any case for a local variable :) trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp http://reviewboard.kde.org/r/2738/#comment3353 don't need to check this; delete 0; is completely valid. so just: delete m_wLayout.data(); the clear() on the next line isn't needed either - Aaron On 2010-01-29 19:32:53, loureiro wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/ --- (Updated 2010-01-29 19:32:53) Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson Cavalcanti. Summary --- This is a small patch that fix a segmentation fault at plasma_applet_animation_example when we close the window. Basically I remove the delete sentence at the RotationStackedAnimation's destruct, I made it because I think when we create a QGraphicsLinearLayout passing a widget that widget will be the owner and responsible to delete it as well its children elements and running the example under valgrind I don't get leaks. Diffs - trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1082016 trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1082016 trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1082016 Diff: http://reviewboard.kde.org/r/2738/diff Testing --- Thanks, loureiro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-devel Digest, Vol 19, Issue 67
QString hadn't done the trick with WebView, but KUrl(url) done the trick. thanks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Idea: Window management for 4.5
2010/1/29 Jonathan Schmidt-Dominé - Developer de...@the-user.org
Hi Plasma-Devs!
Well, I'm not one but ... still, I guess I bring some issues that, thought
deeper, could either help turning this ideas into something or sinking 'em
down. ;)
Comments? Suggestions? Ideas?
I like the idea of getting rid of systray icons (or taskbar entries),
whenever systray icons also manage windows (amarok, kopete, ...). However,
having one behaviour to icon and another for text would possibly confuse
users, even because it's not very discoverable.
I myself have been thinking about taskbar items bringing systray icons's
menu but in the same context-menu. But don't know if it'd be too cluttered
sometimes.
On notifications above their own taskbar items (I also spent a little time
with this idea before -- but not that much to solve this issue, really) the
problem I see is when amarok and firefox (in the example) notify something:
where do the notifications go? Either they'd cover each other or get beside
each other (getting far from their taskbar entries -- and what if
konversation notifies something, too?!) or even be on top of each other (but
aligned with their taskbar entries), which would just look weird.
Do you see reasonable solutions for these issues?
--
J (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix segmentation fault at plasma_applet_animation_example
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/ --- (Updated 2010-01-29 20:25:39.054487) Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson Cavalcanti. Changes --- Fixed the changes commented by aseigo. Summary --- This is a small patch that fix a segmentation fault at plasma_applet_animation_example when we close the window. Basically I remove the delete sentence at the RotationStackedAnimation's destruct, I made it because I think when we create a QGraphicsLinearLayout passing a widget that widget will be the owner and responsible to delete it as well its children elements and running the example under valgrind I don't get leaks. Diffs (updated) - trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1082139 trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1082139 trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1082139 trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1082139 Diff: http://reviewboard.kde.org/r/2738/diff Testing --- Thanks, loureiro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Idea: Window management for 4.5
On January 29, 2010, J Janz wrote: I myself have been thinking about taskbar items bringing systray icons's menu but in the same context-menu. But don't know if it'd be too cluttered sometimes. solvable by putting it in a submenu. -- 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: Idea: Window management for 4.5
I like the idea of getting rid of systray icons (or taskbar entries), whenever systray icons also manage windows (amarok, kopete, ...). However, having one behaviour to icon and another for text would possibly confuse users, even because it's not very discoverable. E.g. you could add a thin line to make it clear that there are two sections. I think it is somekind intuitive because you associate the icon with the application and the title with the window. I myself have been thinking about taskbar items bringing systray icons's menu but in the same context-menu. But don't know if it'd be too cluttered sometimes. Icons and texts are large enough, so why shouldn't we use the space? On notifications above their own taskbar items (I also spent a little time with this idea before -- but not that much to solve this issue, really) the problem I see is when amarok and firefox (in the example) notify something: where do the notifications go? Either they'd cover each other or get beside each other (getting far from their taskbar entries -- and what if konversation notifies something, too?!) or even be on top of each other (but aligned with their taskbar entries), which would just look weird. First of all: More than 3 notifications are alway confusing. So there must be ways to reduce space-usage. 2. It could be configuratable. 3. If you can hide the notifications per application, it would not be a real problem to indicate that there is another notification. A smaller version could be displayed somewhere inside the item. Jonathan Automatisch eingefügte Signatur: Es lebe die Freiheit! Stoppt den Gebrauch proprietärer Software! Operating System: GNU/Linux Kernel: Linux 2.6.31.8-0.1-default Distribution: openSuSE 11.2 Qt: 4.6.1 KDE: 4.4.60 (KDE 4.4.60 (KDE 4.5 = 20100120)) release 3 KMail: 1.13.0 http://gnu.org/ http://kde.org/ http://windows7sins.org/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix segmentation fault at plasma_applet_animation_example
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/#review3973 --- Ship it! :)) - Aaron On 2010-01-29 20:25:39, loureiro wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2738/ --- (Updated 2010-01-29 20:25:39) Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson Cavalcanti. Summary --- This is a small patch that fix a segmentation fault at plasma_applet_animation_example when we close the window. Basically I remove the delete sentence at the RotationStackedAnimation's destruct, I made it because I think when we create a QGraphicsLinearLayout passing a widget that widget will be the owner and responsible to delete it as well its children elements and running the example under valgrind I don't get leaks. Diffs - trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1082139 trunk/KDE/kdelibs/plasma/animations/rotationstacked_p.h 1082139 trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1082139 trunk/KDE/kdelibs/plasma/animations/stackedlayout.cpp 1082139 Diff: http://reviewboard.kde.org/r/2738/diff Testing --- Thanks, loureiro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Idea: Window management for 4.5
Please remove the other message!!! I like the idea of getting rid of systray icons (or taskbar entries), whenever systray icons also manage windows (amarok, kopete, ...). However, having one behaviour to icon and another for text would possibly confuse users, even because it's not very discoverable. E.g. you could add a thin line to make it clear that there are two sections. I think it is somekind intuitive because you associate the icon with the application and the title with the window. I myself have been thinking about taskbar items bringing systray icons's menu but in the same context-menu. But don't know if it'd be too cluttered sometimes. Icons and texts are large enough, so why shouldn't we use the space? On notifications above their own taskbar items (I also spent a little time with this idea before -- but not that much to solve this issue, really) the problem I see is when amarok and firefox (in the example) notify something: where do the notifications go? Either they'd cover each other or get beside each other (getting far from their taskbar entries -- and what if konversation notifies something, too?!) or even be on top of each other (but aligned with their taskbar entries), which would just look weird. First of all: More than 3 notifications are alway confusing. So there must be ways to reduce space-usage. 2. It could be configuratable. 3. If you can hide the notifications per application, it would not be a real problem to indicate that there is another notification. A smaller version could be displayed somewhere inside the item. Jonathan Automatisch eingefügte Signatur: Es lebe die Freiheit! Stoppt den Gebrauch proprietärer Software! Operating System: GNU/Linux Kernel: Linux 2.6.31.8-0.1-default Distribution: openSuSE 11.2 Qt: 4.6.1 KDE: 4.4.60 (KDE 4.4.60 (KDE 4.5 = 20100120)) release 3 KMail: 1.13.0 http://gnu.org/ http://kde.org/ http://windows7sins.org/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Calendar data engine widget future plans
On January 29, 2010, John Layt wrote: On Friday 29 January 2010 19:46:38 Aaron J. Seigo wrote: On January 29, 2010, John Layt wrote: * Support multiple holidays on each day i think we already do internally, but we don't visually display this day has more than one holiday The data engine does read and return multiple holidays, but the calendar widget only uses a QHash to store them so no duplicates there. It's easily fixed by making it a QMultiHash and retrieving all keys. yes, that would be sensible. * Tool-tip on hover over day showing any holidays right now that's done with a click. it certainly has its draw backs, and a tooltip sounds like it might work, my only concern is covering the rest of the calendar which could be annoying. I'm not a big fan of the current expander, especially how it flickers and jumps, not smooth at all, but it does have the advantage of leaving the entire month visible while having lots of room for a list of events. The tool-tip could get in the way a lot and be a bit cramped. cramped isn't a problem, we are experts a making big tooltips in plasma ;) but getting in the way could be an issue. but yes, it seems we are in agreement that the current solution is ok, but not great. the biggest probems to me are the jumping and flickering which you also mention (which means we need to improve extenders more, rather than use that as a reason to avoid them by itself :) and it also takes clicking on the day which isn't as convenient or as obvious as something that appears as you mouse over. something to chew on while you work further on the backend stuff. i think the kde pim people likely have more experience in these matters than we do, and so it would be good to bring them into the discussion early on as well. best would be if the plasma calendar and what we see in korganizer harmonizes visually. i think the plasma calendar should remain simple and provide more of an overview than korganizer does, but they should work together visually as well as functionally imo. Agreed. I think the pim guys are working on KOrganizer this release cycle, so it will be a good time to co-ordinate. Their current Month Table ah, perfect :) * Do we provide users the option of choosing the highlight method for each holiday type, or not to highlight some types? if we do, this should be desktop-wide imho. Yes, I was thinking that, but I want to try it out at an app level first to see if it is practical before moving it to desktop level. makes sense; as long as we don't accidentally put it in all the apps and end up needing to later reunify everything. but i know you're better than that and so i shouldn't worry :) we really want to be able to show, simultaneously: * this day has holidays * this day has appointments * this day is a non-working day That's a very clear summary of it, simple really :-) Based on most common usage I've seen perhaps: Appointment = Bold day number Non-working = Darker shaded background (includes weekends) Holiday = halo with colour possibly varying based on type The bold day number is almost universal (KOrg, Google, Gnome, Evolution, Orage, Sunbird), and shading is fairly common for weekends. i think we have a winner then :) i do like the corner being colored to show an appointment booking, as you mentioned S60 does. Blackberry does the same. that may be a limitation of the low color counts and resolutions they deal with, however. not to mention _crappy_ text/font quality. this sounds like a job for visual design: how to communicate three piece of boolean information in a small space using color and shape only. What we need is Edward Tufte :-) lol Any increase in the detail in each day cell would probably mean removing the graduated fill to keep things looking clean. very true; busy bars is probably better indeed. -- 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
