Re: Tokamak III Wrap Up
On Monday 07 September 2009, 18:53 Mario Fux wrote: > Greets from Zurich > Mario Just to let you know that besides some problems, I just did bread today and it works (TM) :) Ah, and the popcorn hour is also working perfectly :)..Maybe this is the next "mysterious device" that we should put kde in ? ;) Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
Am Montag, 7. September 2009 schrieb Marco Martin: Good morning > > > On Sunday 06 September 2009 15:26:25 Dario Freddi wrote: > > > > Ah, Sebastian, did you download our commercials from the camera? :D > > > > > > Nope, it's not my camera, I think it's Mario's. I hope he'll do it, as > > > it looks like I'll be catching up with stuff here at home this week and > > > won't have a lot of time to fiddle with videos... > > > > Yes. My plan is to do it tomorrow in the office. > > if there still were some doubts about tat: > you rock! :D Thx a lot ;-). Miss you guys @sebas: Please fill in the article one or two sentences about my plans to organize a bigger sprint in the next summer. In the house "Maria am Weg" http://www.hausranda.ch and if groups of KDE are interested, mail me. Thx. @all: There are some parts which stayed in Randa and are not mine: - USB cable from Canon (white) - Power Supply from Canon (black) - T-Shirt - Power connecter (afaik sebas') - Sleeping back (afaik asraniel's) Greets from Zurich Mario ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
On September 7, 2009, Jon A. Cruz wrote: > On Sep 7, 2009, at 11:54 AM, Marco Martin wrote: > > now i'm not sure about the current status of the tcp transport of > > dbus, but > > once it works i don't see particular problems, big endian machines > > would have > > to invert the bytes of the image by hand, that is something that > > somebody will > > inevitably have to do in a mixed environment. i think it's possible > > to avoid > > an extra field for that anyways > > A general approach has been to define things as network byte order... > aka big-endian. yes, this would make sense imo. while there is no non-local parts to this system today, it likely will eventually have to deal with such things. -- 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 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: Tokamak III Wrap Up
On Monday 07 September 2009 22:18:16 Dario Freddi wrote: > In data lunedì 07 settembre 2009 22:13:34, Sebastian Kügler ha scritto: > > I've asked the openSuse people if they would like to host Tokamak III in > > February, and they're happy to. The premises and everything looks really > > good, and with some details such as date sorted, T4 is go :) > > Sebastian, about this: any chance for it to be late February? Early > february is exam period here in Italy, usually. Don't worry, Will checks which constraints there are at suse in February, then we'll try to find a date that fits most people best, that'll come up shortly. -- 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: Tokamak III Wrap Up
In data lunedì 07 settembre 2009 22:13:34, Sebastian Kügler ha scritto: > I've asked the openSuse people if they would like to host Tokamak III in > February, and they're happy to. The premises and everything looks really > good, and with some details such as date sorted, T4 is go :) Sebastian, about this: any chance for it to be late February? Early february is exam period here in Italy, usually. > > > Sebas - I'll give you screenshots of the widgets explorer in a minute, > > ok?! > > Cool! The text is nearly ready thanks to everyone's comments and Jos' mad > dot- editing, I'll publish it somewhen tomorrow morning, my timezone. > > Cheers, > -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: Tokamak III Wrap Up
On Monday 07 September 2009 21:28:53 Ana Cecília Martins Barbosa wrote: > The trip back to Brazil was great! - me and Arthur went to the train > station wearing only one jacket and the weather was 2 degrees Celsius > cold! How evolved are we?! I'm quite impressed. > Sebas, the article is great and I have no complains about it - btw, thanks > for calling me designer ;) You are :) > I haven't made a blog post about tokamak yet, but you should now how > thankful I am to be given the opportunity of being part of this - this was > one of the most exciting/significative experiences I've ever had. Each one > of you contributte to this community in your own way, and the fact that > everyone is so different, yet so good on what you do, makes this community > the most rich and pleasent group to work with. I've learned so much with > you in these days! > I miss you guys already and I can't wait for the next opportunity to meet > you again! :) I've asked the openSuse people if they would like to host Tokamak III in February, and they're happy to. The premises and everything looks really good, and with some details such as date sorted, T4 is go :) > Sebas - I'll give you screenshots of the widgets explorer in a minute, ok?! Cool! The text is nearly ready thanks to everyone's comments and Jos' mad dot- editing, I'll publish it somewhen tomorrow morning, my timezone. Cheers, -- 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: KNotificationItem specification - first draft
On Sep 7, 2009, at 11:54 AM, Marco Martin wrote: > now i'm not sure about the current status of the tcp transport of > dbus, but > once it works i don't see particular problems, big endian machines > would have > to invert the bytes of the image by hand, that is something that > somebody will > inevitably have to do in a mixed environment. i think it's possible > to avoid > an extra field for that anyways A general approach has been to define things as network byte order... aka big-endian. Regardless, it should be made explicit and the future use explicitly covered. If I recall correctly, X11 address this for datatypes by being explicit about data types and sizes, and then for multi-byte values the system automatically handles client/server differences in byte order. This does come up for clipboard and drag-n-drop operations also. In fact, I recall having some problems with Qt/KDE color types not being defined correctly. The color format was 16-bit component values, but Qt/KDE gave 8-bit format for the 16-bit data. In that case 16-bit format would be converted automatically by the transport, but 8-bit format required some kludges and trying to standardize on the byte order, etc. The most likely cause was simply oversight on the part of Trolltech, combined with not enough time/resources to run some heterogenous tests. It probably would be good if new protocols would avoid problems initially. Then we won't have to add work-arounds and such later. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
Hello you guys! :) The trip back to Brazil was great! - me and Arthur went to the train station wearing only one jacket and the weather was 2 degrees Celsius cold! How evolved are we?! Sebas, the article is great and I have no complains about it - btw, thanks for calling me designer ;) I haven't made a blog post about tokamak yet, but you should now how thankful I am to be given the opportunity of being part of this - this was one of the most exciting/significative experiences I've ever had. Each one of you contributte to this community in your own way, and the fact that everyone is so different, yet so good on what you do, makes this community the most rich and pleasent group to work with. I've learned so much with you in these days! I miss you guys already and I can't wait for the next opportunity to meet you again! :) Sebas - I'll give you screenshots of the widgets explorer in a minute, ok?! cheers! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
On Sep 7, 2009, at 2:36 AM, Aurélien Gâteau wrote: > > A name like KSystemTrayItem would avoid such confusions. I know it is > probably not very appropriate because it describe a visualization > rather > than the content, but I feel it would still be better than > KNotificationItem (Think about a new developer faced with choosing > between the KNotification and KNotificationItem classes...) Even in Microsoft Windows, it has never been called "system tray". They had been careful from the beginning to call it the "notification area" in APIs, user documentation, etc. Early on some people outside of MS noticed "systray.exe" and so gave it a nickname. So for developers who look into this at all, even Windows developers, should be able to cope with the industry standard term. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
On Sep 7, 2009, at 10:11 AM, Marco Martin wrote: > At the moment, (should make it more clear in the spec) is ARGB and > is not > designed to be network transparent, so the endian should be the same > of the > machine for both the client and the server I'd say this point was a HUGE red flag. For commercial app development (and here at home too) I've had to support remote X11 between different architectures. Especially since Mac's are officially UNIX(tm) one does not even have to install Linux on a mac to take advantage of this (although I often do). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [dot] Tokamak III Wrap Up
On Saturday 05 September 2009 14:53:18 Sebastian Kügler wrote: > Fellow Plasmaniacs, > > I hope you all got home well, and those of you who haven't made it yet: > have a safe and pleasant trip! > > I've spent the better part (actually the better part of the journey I was > *not* sleeping or having lunch in the train's restaurant ;-)) to writing > up the results of last week's Plasma cuddling in the Alps. Maybe I hadn't > realized it yet, but HOLY CRAP -- what a lot of big achievements. > > As such, the tone of this article is pretty bold. I've quoted some people > (notably aseigo, pinda, morpheuz, these people, and everybody else should > fact-check the article so we don't make false promises. If you feel > uncomfortable with some of the contents of this article, please let me > know and we'll change it before publishing. I'll also add a couple of > photos and screenshots to the article. Ana, can you give me a nice-looking > screenshot of the widgets explorer? Marco / Artur, please send me one of > the netbook shell. Dario, I need a policykit screenie. Thanks! > > As to reviewing, especially the following is needed: > > - proof-reading by native speaker > - fact-checks (who did what) > - spell-checking andn correct attribution of names > - what else did I forget? > > I plan to publish the article on Tuesday and will poke the press a bit to > write about it, so please be quick by providing feedback, fresh news is > more likely to be re- published by third parties after all -- and we > certainly have created interesting stuff to write about. > > Maybe also a personal note to everybody involved: I really enjoyed working > with everybody, and to me T3 was serious fun. You rock! Thanks for having > me being part of such a great team. I mean it. > > Thanks, Attached a diff with quite a few fixes. Hope it helps (and actually applies properly, I'm not that good with this stuff). grtz Jos P --- tokamak3-dot.html 2009-09-07 19:08:29.0 +0200 +++ tokamak3-dot-edited.html 2009-09-07 19:08:14.0 +0200 @@ -1,20 +1,20 @@ Third Plasma Summit Lifts KDE Desktop to Higher Grounds -Last week, the fourth Plasma developers meeting was held in Randa, Switzerland. 15 developers from 3 continents came to Randa, Canton Wallis in Switzerland to work on Plasma's code, design new ideas and concepts and to strengthen their bonds as a sub-community within KDE. Topics of this third Plasma sprint, which is named after a plasma fusion reactor included, but were not limited to Plasma on mobile devices, network-enabled Plasma widgets, a richer user interface thanks to a new animation framework, deeper integration of web services in to the Plasma shell, semantic awareness of Plasma components, secure privilege elevation, polishing of the existing functionality, and many others. The results of Tokamak III are, with all due modesty, nothing short of mind-blowing and display the health and swift pace of development of the whole KDE community. Plasma lead developer Aaron Seigo wraps up "It's been one of the longest KDE sprints ever, and after a week, we're all quite exhausted. Looking back at the results, however, we've shown impressive progress all over the KDE desktop shell. We're reaching out to new use case, new developers, new devices. Meanwhile the social aspects within the Plasma team continue to impress me. The Plasma team has grown into a small community, a group of friends that have set out to revoluionize the desktop. With the previous KDE releases, we've mainly focused on providing and improving existing technology, now we're pushing the boundaries of the Free Desktop. Looking at the results that have materialized over the past week, this is the Plasma promise coming true. And we've only just begun..." +Last week, the third Plasma developers meeting was held in Switzerland. 15 developers from 3 continents came to Randa, Canton Wallis to work on Plasma's code, design new ideas and concepts and to strengthen their bonds as a sub-community within KDE. Topics of this third Plasma sprint, which is named after a plasma fusion reactor included, but were not limited to Plasma on mobile devices, network-enabled Plasma widgets and a richer user interface thanks to a new animation framework. Furthermore deeper integration of web services in to the Plasma shell, semantic awareness of Plasma components, secure privilege elevation and polishing of the existing functionality, among many other things, were on the agenda. The results of Tokamak III are, with all due modesty, nothing short of mind-blowing and display the health and swift pace of development of the whole KDE community. Plasma lead developer Aaron Seigo wraps up "It's been one of the longest KDE sprints ever, and after a week, we're all quite exhausted. Looking back at the results, however, we've shown impressive progress all over the KDE desktop shell. We're reaching out to new use cases, new developers, new devices. Meanwhile the social asp
Re: KNotificationItem specification - first draft
On Monday 07 September 2009, Jon A. Cruz wrote: > On Sep 7, 2009, at 10:11 AM, Marco Martin wrote: > > At the moment, (should make it more clear in the spec) is ARGB and > > is not > > designed to be network transparent, so the endian should be the same > > of the > > machine for both the client and the server > > I'd say this point was a HUGE red flag. > > For commercial app development (and here at home too) I've had to > support remote X11 between different architectures. Especially since > Mac's are officially UNIX(tm) one does not even have to install Linux > on a mac to take advantage of this (although I often do). right now when the dbus spec is not supported (i.e. local instances of NotificationItemWatcher and NotificationHost aren't on the bus) it falls back to the xembed based systray, and is what happens also when using remote displays, given that on the remote machine doesn't run a full blown workspace. now i'm not sure about the current status of the tcp transport of dbus, but once it works i don't see particular problems, big endian machines would have to invert the bytes of the image by hand, that is something that somebody will inevitably have to do in a mixed environment. i think it's possible to avoid an extra field for that anyways -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
On Monday 07 September 2009, Aurélien Gâteau wrote: > Marco Martin wrote: > > On Monday 07 September 2009, Aurélien Gâteau wrote: > >> Hi, > >> > >> I am probably a bit late at this, but thought I would ask anyway. > >> > >> Why did you choose the term "KNotificationItem"? I am afraid this is > >> going to cause confusion with the existing notification systems. > > > > the choice of the name has been a bit painful, it has gone trough several > > renames. > > iirc this was chisen because in gnome and windows the systray is already > > called notification area and we didn't want to confuse the current > > implementation with the protocol, since the last goal is to remove some > > of the icons from the system tray, probably representing the items of > > "application" category in the taskbar, this would make the "SystemTray" > > term less meaningful > > I understand the reasons, but I still think this is confusing. Is it too > late to change the name, or can it still be brainstormed? not until 4.4.0 would mean to break and unbreak the whole trunk again but oh, well, got used to :) but has to be -really- worth it and i don't see really better names right now, systemtray is even more problematic > >> PS: To get more feedback about the spec, I suggest you generate an html > >> output of it and upload it somewhere. > > > > yeah, good idea, here it is: > > http://www.notmart.org/misc/notificationitem > > Thanks for this! > > Here are some corrections/suggestions: > > 3.3. Signals > 3.3.1. NewTitle > > I suggest reporting the new title as a signal parameter to avoid a > round-trip from the host to the item to fetch the text. > > 4.1.4. RegisterNotificationHost > > Wrong method name in the prototype whoops, corrected > > 7. Markup > > Supporting markup means opening a whole can of worms: you can't count on yeah, i know :/ > app developers to properly escape the content they send and you may end > up with using heuristics to determine whether the '<' character is a > single character or the beginning of a tag. > > Since the content of tooltips aim to be short, I suggest not supporting > markup. i would love to dictate a really simple aspect, i've seen that many aplications wrote their own tooltips to make really fancy stuff, since with this spec this wouldn't be possible anymore (again the problem is to know that those are icons and where it is) i don't think it's really realistic to ask everybody to drop that feature, we dropped some of them already that makes people not really happy... > If you think this is too restrictive, then I suggest to either: > State that everything is markup and a '<' character should *always* be > escaped to '<'. i think i like more this way > or: > State that if an item wishes to use markup, then it must enclose the > whole text in a tag. > > In both cases you want to check the first implementations of > NotificationHost strictly enforce these rules. yes. and maybe strip the not allowed tags? how it was done in the Notification spec in the end? > 8. Icons > > You should also explicitly state the byte order of the image-data. Is it > ARGB, RGBA? is it endian-independent? > > Aurelien At the moment, (should make it more clear in the spec) is ARGB and is not designed to be network transparent, so the endian should be the same of the machine for both the client and the server -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Convert weather code to use KUnitConversion (kdeplasma-addons)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1530/#review2263 --- Ship it! Looks fine, SHIP IT! - Shawn On 2009-09-07 09:37:35, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1530/ > --- > > (Updated 2009-09-07 09:37:35) > > > Review request for Plasma. > > > Summary > --- > > Convert weather code to use KUnitConversion. > > > Diffs > - > > /trunk/KDE/kdeplasma-addons/applets/weather/CMakeLists.txt 1020435 > /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.h 1020435 > /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.cpp 1020435 > /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.h 1020435 > /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.cpp > 1020435 > /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.h 1020435 > /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.cpp 1020435 > /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.h 1020435 > /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.cpp > 1020435 > > Diff: http://reviewboard.kde.org/r/1530/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Convert weather code to use KUnitConversion (kdebase)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1529/#review2262 --- Ship it! Looks good to me, SHIP IT! - Shawn On 2009-09-07 09:37:20, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1529/ > --- > > (Updated 2009-09-07 09:37:20) > > > Review request for Plasma. > > > Summary > --- > > Convert weather code to use KUnitConversion. > > > Diffs > - > > > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp > 1020445 > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.cpp > 1020445 > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.cpp > 1020445 > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.h > 1020445 > > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.cpp > 1020445 > > Diff: http://reviewboard.kde.org/r/1529/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
On Monday 07 September 2009, Mario Fux wrote: > Am Montag, 7. September 2009 schrieb Sebastian Kügler: > > Good morning > > > On Sunday 06 September 2009 15:26:25 Dario Freddi wrote: > > > Ah, Sebastian, did you download our commercials from the camera? :D > > > > Nope, it's not my camera, I think it's Mario's. I hope he'll do it, as it > > looks like I'll be catching up with stuff here at home this week and > > won't have a lot of time to fiddle with videos... > > Yes. My plan is to do it tomorrow in the office. if there still were some doubts about tat: you rock! :D > > griits > Mario > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
On Monday 07 September 2009 13:27:52 Mario Fux wrote: > Am Montag, 7. September 2009 schrieb Sebastian Kügler: > > Good morning > > > On Sunday 06 September 2009 15:26:25 Dario Freddi wrote: > > > Ah, Sebastian, did you download our commercials from the camera? :D > > > > Nope, it's not my camera, I think it's Mario's. I hope he'll do it, as it > > looks like I'll be catching up with stuff here at home this week and > > won't have a lot of time to fiddle with videos... > > Yes. My plan is to do it tomorrow in the office. Awesome :) -- 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: KNotificationItem specification - first draft
Marco Martin wrote: > On Monday 07 September 2009, Aurélien Gâteau wrote: >> Hi, >> >> I am probably a bit late at this, but thought I would ask anyway. >> >> Why did you choose the term "KNotificationItem"? I am afraid this is >> going to cause confusion with the existing notification systems. > > the choice of the name has been a bit painful, it has gone trough several > renames. > iirc this was chisen because in gnome and windows the systray is already > called notification area and we didn't want to confuse the current > implementation with the protocol, since the last goal is to remove some of > the > icons from the system tray, probably representing the items of "application" > category in the taskbar, this would make the "SystemTray" term less meaningful I understand the reasons, but I still think this is confusing. Is it too late to change the name, or can it still be brainstormed? >> PS: To get more feedback about the spec, I suggest you generate an html >> output of it and upload it somewhere. > yeah, good idea, here it is: > http://www.notmart.org/misc/notificationitem Thanks for this! Here are some corrections/suggestions: 3.3. Signals 3.3.1. NewTitle I suggest reporting the new title as a signal parameter to avoid a round-trip from the host to the item to fetch the text. 4.1.4. RegisterNotificationHost Wrong method name in the prototype 7. Markup Supporting markup means opening a whole can of worms: you can't count on app developers to properly escape the content they send and you may end up with using heuristics to determine whether the '<' character is a single character or the beginning of a tag. Since the content of tooltips aim to be short, I suggest not supporting markup. If you think this is too restrictive, then I suggest to either: State that everything is markup and a '<' character should *always* be escaped to '<'. or: State that if an item wishes to use markup, then it must enclose the whole text in a tag. In both cases you want to check the first implementations of NotificationHost strictly enforce these rules. 8. Icons You should also explicitly state the byte order of the image-data. Is it ARGB, RGBA? is it endian-independent? Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
Am Montag, 7. September 2009 schrieb Sebastian Kügler: Good morning > On Sunday 06 September 2009 15:26:25 Dario Freddi wrote: > > Ah, Sebastian, did you download our commercials from the camera? :D > > Nope, it's not my camera, I think it's Mario's. I hope he'll do it, as it > looks like I'll be catching up with stuff here at home this week and won't > have a lot of time to fiddle with videos... Yes. My plan is to do it tomorrow in the office. griits Mario ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
On Monday 07 September 2009, Aurélien Gâteau wrote: > Hi, > > I am probably a bit late at this, but thought I would ask anyway. > > Why did you choose the term "KNotificationItem"? I am afraid this is > going to cause confusion with the existing notification systems. the choice of the name has been a bit painful, it has gone trough several renames. iirc this was chisen because in gnome and windows the systray is already called notification area and we didn't want to confuse the current implementation with the protocol, since the last goal is to remove some of the icons from the system tray, probably representing the items of "application" category in the taskbar, this would make the "SystemTray" term less meaningful > A name like KSystemTrayItem would avoid such confusions. I know it is > probably not very appropriate because it describe a visualization rather > than the content, but I feel it would still be better than > KNotificationItem (Think about a new developer faced with choosing > between the KNotification and KNotificationItem classes...) > > Aurelien > > PS: To get more feedback about the spec, I suggest you generate an html > output of it and upload it somewhere. yeah, good idea, here it is: http://www.notmart.org/misc/notificationitem Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III Wrap Up
On Sunday 06 September 2009 15:26:25 Dario Freddi wrote: > Ah, Sebastian, did you download our commercials from the camera? :D Nope, it's not my camera, I think it's Mario's. I hope he'll do it, as it looks like I'll be catching up with stuff here at home this week and won't have a lot of time to fiddle with videos... -- 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
Review Request: Convert weather code to use KUnitConversion (kdeplasma-addons)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1530/ --- Review request for Plasma. Summary --- Convert weather code to use KUnitConversion. Diffs - /trunk/KDE/kdeplasma-addons/applets/weather/CMakeLists.txt 1020435 /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.h 1020435 /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.cpp 1020435 /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.h 1020435 /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.cpp 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.h 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.cpp 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.h 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.cpp 1020435 Diff: http://reviewboard.kde.org/r/1530/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KNotificationItem specification - first draft
Hi, I am probably a bit late at this, but thought I would ask anyway. Why did you choose the term "KNotificationItem"? I am afraid this is going to cause confusion with the existing notification systems. A name like KSystemTrayItem would avoid such confusions. I know it is probably not very appropriate because it describe a visualization rather than the content, but I feel it would still be better than KNotificationItem (Think about a new developer faced with choosing between the KNotification and KNotificationItem classes...) Aurelien PS: To get more feedback about the spec, I suggest you generate an html output of it and upload it somewhere. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Convert weather code to use KUnitConversion (kdebase)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1529/ --- Review request for Plasma. Summary --- Convert weather code to use KUnitConversion. Diffs - /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.h 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.cpp 1020445 Diff: http://reviewboard.kde.org/r/1529/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
