Re: Review Request: Unified ItemBackground in new Device Notifier

2009-10-05 Thread Aaron Seigo 


> On 2009-10-06 02:00:26, Chani wrote:
> > /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp, 
> > line 489
> > 
> >
> > commented out code... is it dead? should it be removed?

yes, removed now in my local copy


> On 2009-10-06 02:00:26, Chani wrote:
> > /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h, 
> > line 306
> > 
> >
> > there are two of them now, with the exact same comment. can you change 
> > the comment to explain how they're different?

fixed


> On 2009-10-06 02:00:26, Chani wrote:
> > /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h, line 
> > 196
> > 
> >
> > grammar!

details ;P


- Aaron


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1790/#review2559
---


On 2009-10-05 23:27:10, Aaron Seigo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1790/
> ---
> 
> (Updated 2009-10-05 23:27:10)
> 
> 
> Review request for Plasma, Jacopo De Simoi and Giulio Camuffo.
> 
> 
> Summary
> ---
> 
> proof of concept showing how the item background could be unified into 
> NotifierDialog; requires today's libplasma for fixes to the ItemBackground 
> widget
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.cpp 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp 
> 1031762 
> 
> Diff: http://reviewboard.kde.org/r/1790/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aaron
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Unified ItemBackground in new Device Notifier

2009-10-05 Thread Chani 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1790/#review2559
---

Ship it!


I'm a little fuzzy on what's going on with the two items near the end; my brain 
seems to have just run out of power halfway through :)


/trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h


grammar!



/trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h


there are two of them now, with the exact same comment. can you change the 
comment to explain how they're different?



/trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp


commented out code... is it dead? should it be removed?


- Chani


On 2009-10-05 23:27:10, Aaron Seigo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1790/
> ---
> 
> (Updated 2009-10-05 23:27:10)
> 
> 
> Review request for Plasma, Jacopo De Simoi and Giulio Camuffo.
> 
> 
> Summary
> ---
> 
> proof of concept showing how the item background could be unified into 
> NotifierDialog; requires today's libplasma for fixes to the ItemBackground 
> widget
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.cpp 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h 
> 1031762 
>   /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp 
> 1031762 
> 
> Diff: http://reviewboard.kde.org/r/1790/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aaron
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add an hidden option to set a translucent background for DesktopView

2009-10-05 Thread Lucas Murray 


> On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > anything but the desktop shell painting the wallpaper is poor design. the 
> > window manager does not have enough knowledge of what is happening in the 
> > shell to do so properly. what, exactly, is the benefit of letting compiz 
> > draw the wallpaper? if it's simply visual bling, i'm really not interested 
> > in encouraging it by adapting plasma-desktop to such a broken idea.
> 
> wearenotalone wrote:
> Thanks for your feedback!
> 
> My intention was on the one hand to enhance the user experience for power 
> users and on the other hand to increase (respectively restore) the 
> compatibility with other applications like compiz. The user should have the 
> right and the freedom to decide for themselves. With this patch, the user is 
> able to use the wallpaper plugin of Compiz, if he really wants to. Any other 
> user does not have to deal with this option (because hidden), due to the 
> default setting "false" this may not cause any disadvantages / speed 
> penalties for him.
> 
> I use Compiz with multiple viewports; using the wallpaper plugin, I can 
> easily distinguish between different viewports. In addition, KDE4 looks 
> really great in cooperation with Compiz. To develop a proper mapping between 
> the viewports of Compiz and the desktop / activities of plasma, I simply lack 
> the experience. I did not want to wait until someone else does this, instead 
> i wanted to tackle the problem by myself. My goal was to fix the regression 
> in 4.3.1 compared to 4.2 with minimal impact on existing code. Primary goal 
> was to change the existing design, behavior and code as little as possible. I 
> also tried to stick as accurately as possible to the naming scheme and the 
> coding style of the original authors.
> 
> I hope that you can understand my arguments and allow us to use Compiz 
> and KDE 4 together again.
> 
> Yours sincerely,
> WANA
> p.s. The corrected patch will follow later.
> 
> Aaron Seigo wrote:
> "The user should have the right and the freedom to decide for themselves"
> 
> they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms.
> 
> "Any other user does not have to deal with this option"
> 
> the developers deal with maintaining it, any bug reports that result from 
> it and users pay for that overhead indirectly. there is no such thing as a 
> patch that adds a feature that does no harm; the negative of more feature 
> weight must be offset by benefit. in this case, it also goes against some 
> design fundamentals.
> 
> it is therefore my decision that this patch which introduces a 
> purpose-specific hidden config option is not desirable to the upstream 
> project.
> 
> "My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal 
> impact on existing code."
> 
> it was coincidental that this worked in 4.2; it was not an intentional 
> feature.
> 
> "Primary goal was to change the existing design, behavior and code as 
> little as possible. I also tried to stick as accurately as possible to the 
> naming scheme and the coding style of the original authors."
> 
> i do appreciate that.
> 
> as Sebas noted on the mailing list, this really ought to be a property of 
> the wallpaper that the View can check. this would mean some new property in 
> Plasma::Wallpaper and a way to signal that it has changed so the view can 
> react if it wishes to. how to do that cleanly is the question. i don't think 
> Wallpaper should have something specific to this, but perhaps some sort of 
> properties system that can be set/changed by the Wallpaper (allowing us to 
> add things over time and keep the API straightforward from the start).
> 
> wearenotalone wrote:
> That sounds reasonable, but it is far too difficult for me. I will 
> continue to manually patch the Debian packages. If someone wants to use 4.3.1 
> with the wallpaper plugin, he will find all necessary information in the the 
> bug report. I will now discard this review request, ok?
>
> 
> Nathanael Schilling wrote:
> "they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms."
> 
> In my opinion, designing something around the code, i.e. setting all 
> configurations in the source code is a design flaw as well. Sure people are 
> free to modify the code, but that doesn't mean they can (permissions wise) or 
> have the technical knowledge to.  I realize that kde likes to work with 
> itself and that the plasma devs therefore would design plasma around kwin. As 
> plasma is a desktop shell but not a window manager, it would be expected that 
> it is possible to use other window managers/compositors together with plasma, 
> and that plasma would give control to this other compositor/window manager to 
> the furthest extent

Re: New devicenotifier moved to kdereview

2009-10-05 Thread Aaron J. Seigo 
On October 4, 2009, Jacopo De Simoi wrote:
>  now, we believe that it is ready for merging into trunk. Of course we need
>  your feedback first, so grab it, try it out and tell us what you think!

what items should be showing up when i select "all items"? it doesn't show the 
hard disk inside the laptop, for instance, which is kind of what i (naively?) 
expected. is it only devices (fixed or otherwise) that the user can 
mount/unmount?

-- 
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: Review Request: Unified ItemBackground in new Device Notifier

2009-10-05 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1790/
---

(Updated 2009-10-05 23:27:10.347412)


Review request for Plasma, Jacopo De Simoi and Giulio Camuffo.


Changes
---

polishing and little fixes ...


Summary
---

proof of concept showing how the item background could be unified into 
NotifierDialog; requires today's libplasma for fixes to the ItemBackground 
widget


Diffs (updated)
-

  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h 1031762 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.cpp 
1031762 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h 
1031762 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp 
1031762 

Diff: http://reviewboard.kde.org/r/1790/diff


Testing
---


Thanks,

Aaron

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Sebastian Kügler 
On Monday 05 October 2009 17:34:07 Shawn Starr wrote:
> On October 5, 2009 06:44:54 am Sebastian Kügler wrote:
> > So, how about we start on Feb. 19th and the last people depart on the
> > 26th? (That's Friday to Friday.)
> 
> If I am able to attend it could not be on the 19th, for those who know me
>  will know why :(

We'll be meeting for a whole week, so no problem if you can only make it a day 
later. 
(-:
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Dario Freddi 
I'll try my best, can't guarantee anything at the moment though, probably only 
for a short period like the last one.

On Monday 05 October 2009 12:44:54 Sebastian Kügler wrote:
> Hey fellow Plasmoids,
> 
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
>  around the openSuse offices. The next step to make it happen is finding a
>  date. From what I understand, the second half of February seems like a
>  good time. KDE 4.4 will be released beginning of February, so this would
>  fall nicely at the beginning of the 4.5 cycle.
> 
> So, how about we start on Feb. 19th and the last people depart on the 26th?
>  (That's Friday to Friday.)
> 
> Any other proposals for a date?
> 
> Also, who here would like to attend?
> 

-- 
---

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: Review Request: Unified ItemBackground in new Device Notifier

2009-10-05 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1790/
---

(Updated 2009-10-05 18:49:28.837661)


Review request for Plasma, Jacopo De Simoi and Giulio Camuffo.


Summary
---

proof of concept showing how the item background could be unified into 
NotifierDialog; requires today's libplasma for fixes to the ItemBackground 
widget


Diffs (updated)
-

  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h 1031624 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.cpp 
1031645 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h 
1031624 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp 
1031624 

Diff: http://reviewboard.kde.org/r/1790/diff


Testing
---


Thanks,

Aaron

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Unified ItemBackground in new Device Notifier

2009-10-05 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1790/
---

Review request for Plasma, Jacopo De Simoi and Giulio Camuffo.


Summary
---

proof of concept showing how the item background could be unified into 
NotifierDialog; requires today's libplasma for fixes to the ItemBackground 
widget


Diffs
-

  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.h 1031624 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/deviceitem.cpp 
1031645 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.h 
1031624 
  /trunk/kdereview/plasma/applets/devicenotifier-refactor/notifierdialog.cpp 
1031624 

Diff: http://reviewboard.kde.org/r/1790/diff


Testing
---


Thanks,

Aaron

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: configurable default mouse plugins

2009-10-05 Thread Aaron Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1760/#review2554
---

Ship it!


it's a bit odd that ContainmentActionsConfig doesn't have any getters, only 
seters, but i agree that there is no point to having them currently. we may end 
up adding them later, but that is BC.


/dev/null


@since 4.4



/dev/null


newline



/dev/null


newline


- Aaron


On 2009-10-04 00:09:12, Chani wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1760/
> ---
> 
> (Updated 2009-10-04 00:09:12)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this creates a framework for shells to configure the set of default 
> ContainmentActions plugins for each type of containment (desktop, panel, etc).
> 
> the patch to kdebase is small so instead of creating a separate review 
> request I'll paste the important bit here:
> 
> @@ -51,6 +52,17 @@ void DesktopCorona::init()
>  Kephal::Screens *screens = Kephal::Screens::self();
>  connect(screens, SIGNAL(screenAdded(Kephal::Screen *)), 
> SLOT(screenAdded(Kephal::Screen *)));
>  connect(KWindowSystem::self(), SIGNAL(workAreaChanged()), this, 
> SIGNAL(availableScreenRegionChanged()));
> +
> +Plasma::ContainmentActionsPluginsConfig desktopPlugins;
> +desktopPlugins.addPlugin(Qt::NoModifier, Qt::Vertical, "switchdesktop");
> +desktopPlugins.addPlugin(Qt::NoModifier, Qt::MidButton, "paste");
> +desktopPlugins.addPlugin(Qt::NoModifier, Qt::RightButton, "contextmenu");
> +Plasma::ContainmentActionsPluginsConfig panelPlugins;
> +panelPlugins.addPlugin(Qt::NoModifier, Qt::RightButton, "contextmenu");
> +
> +setContainmentActionsDefaults(Plasma::Containment::DesktopContainment, 
> desktopPlugins);
> +setContainmentActionsDefaults(Plasma::Containment::PanelContainment, 
> panelPlugins);
> +
> setContainmentActionsDefaults(Plasma::Containment::CustomPanelContainment, 
> panelPlugins);
>  }
> 
> 
> Diffs
> -
> 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1029909 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1029909 
>   /trunk/KDE/kdelibs/plasma/corona.h 1029909 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1029909 
> 
> Diff: http://reviewboard.kde.org/r/1760/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Chani
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: New devicenotifier moved to kdereview

2009-10-05 Thread Aaron J. Seigo 
On October 5, 2009, Aaron J. Seigo wrote:
> On October 4, 2009, Giulio Camuffo wrote:
> > In data domenica 04 ottobre 2009 20:31:49, Aaron J. Seigo ha scritto:
> > : > On October 4, 2009, Jacopo De Simoi wrote:

> > well, actually you can't open two devices at a time, so if we keep this
> >  behaviour the problem doesn't exist. on the other hand if we change that
> > i think it makes sense, even if i'd say it would introduce some
> > complexity in the code, but i'm not sure about that.
> 
> let me whip up a patch for you to look at and try :)

http://reviewboard.kde.org/r/1790/

-- 
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: Review Request: Add an hidden option to set a translucent background for DesktopView

2009-10-05 Thread Martin Gräßlin 


> On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > anything but the desktop shell painting the wallpaper is poor design. the 
> > window manager does not have enough knowledge of what is happening in the 
> > shell to do so properly. what, exactly, is the benefit of letting compiz 
> > draw the wallpaper? if it's simply visual bling, i'm really not interested 
> > in encouraging it by adapting plasma-desktop to such a broken idea.
> 
> wearenotalone wrote:
> Thanks for your feedback!
> 
> My intention was on the one hand to enhance the user experience for power 
> users and on the other hand to increase (respectively restore) the 
> compatibility with other applications like compiz. The user should have the 
> right and the freedom to decide for themselves. With this patch, the user is 
> able to use the wallpaper plugin of Compiz, if he really wants to. Any other 
> user does not have to deal with this option (because hidden), due to the 
> default setting "false" this may not cause any disadvantages / speed 
> penalties for him.
> 
> I use Compiz with multiple viewports; using the wallpaper plugin, I can 
> easily distinguish between different viewports. In addition, KDE4 looks 
> really great in cooperation with Compiz. To develop a proper mapping between 
> the viewports of Compiz and the desktop / activities of plasma, I simply lack 
> the experience. I did not want to wait until someone else does this, instead 
> i wanted to tackle the problem by myself. My goal was to fix the regression 
> in 4.3.1 compared to 4.2 with minimal impact on existing code. Primary goal 
> was to change the existing design, behavior and code as little as possible. I 
> also tried to stick as accurately as possible to the naming scheme and the 
> coding style of the original authors.
> 
> I hope that you can understand my arguments and allow us to use Compiz 
> and KDE 4 together again.
> 
> Yours sincerely,
> WANA
> p.s. The corrected patch will follow later.
> 
> Aaron Seigo wrote:
> "The user should have the right and the freedom to decide for themselves"
> 
> they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms.
> 
> "Any other user does not have to deal with this option"
> 
> the developers deal with maintaining it, any bug reports that result from 
> it and users pay for that overhead indirectly. there is no such thing as a 
> patch that adds a feature that does no harm; the negative of more feature 
> weight must be offset by benefit. in this case, it also goes against some 
> design fundamentals.
> 
> it is therefore my decision that this patch which introduces a 
> purpose-specific hidden config option is not desirable to the upstream 
> project.
> 
> "My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal 
> impact on existing code."
> 
> it was coincidental that this worked in 4.2; it was not an intentional 
> feature.
> 
> "Primary goal was to change the existing design, behavior and code as 
> little as possible. I also tried to stick as accurately as possible to the 
> naming scheme and the coding style of the original authors."
> 
> i do appreciate that.
> 
> as Sebas noted on the mailing list, this really ought to be a property of 
> the wallpaper that the View can check. this would mean some new property in 
> Plasma::Wallpaper and a way to signal that it has changed so the view can 
> react if it wishes to. how to do that cleanly is the question. i don't think 
> Wallpaper should have something specific to this, but perhaps some sort of 
> properties system that can be set/changed by the Wallpaper (allowing us to 
> add things over time and keep the API straightforward from the start).
> 
> wearenotalone wrote:
> That sounds reasonable, but it is far too difficult for me. I will 
> continue to manually patch the Debian packages. If someone wants to use 4.3.1 
> with the wallpaper plugin, he will find all necessary information in the the 
> bug report. I will now discard this review request, ok?
>
> 
> Nathanael Schilling wrote:
> "they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms."
> 
> In my opinion, designing something around the code, i.e. setting all 
> configurations in the source code is a design flaw as well. Sure people are 
> free to modify the code, but that doesn't mean they can (permissions wise) or 
> have the technical knowledge to.  I realize that kde likes to work with 
> itself and that the plasma devs therefore would design plasma around kwin. As 
> plasma is a desktop shell but not a window manager, it would be expected that 
> it is possible to use other window managers/compositors together with plasma, 
> and that plasma would give control to this other compositor/window manager to 
> the furthest extent

Re: Review Request: Add an hidden option to set a translucent background for DesktopView

2009-10-05 Thread Nathanael Schilling 


> On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > anything but the desktop shell painting the wallpaper is poor design. the 
> > window manager does not have enough knowledge of what is happening in the 
> > shell to do so properly. what, exactly, is the benefit of letting compiz 
> > draw the wallpaper? if it's simply visual bling, i'm really not interested 
> > in encouraging it by adapting plasma-desktop to such a broken idea.
> 
> wearenotalone wrote:
> Thanks for your feedback!
> 
> My intention was on the one hand to enhance the user experience for power 
> users and on the other hand to increase (respectively restore) the 
> compatibility with other applications like compiz. The user should have the 
> right and the freedom to decide for themselves. With this patch, the user is 
> able to use the wallpaper plugin of Compiz, if he really wants to. Any other 
> user does not have to deal with this option (because hidden), due to the 
> default setting "false" this may not cause any disadvantages / speed 
> penalties for him.
> 
> I use Compiz with multiple viewports; using the wallpaper plugin, I can 
> easily distinguish between different viewports. In addition, KDE4 looks 
> really great in cooperation with Compiz. To develop a proper mapping between 
> the viewports of Compiz and the desktop / activities of plasma, I simply lack 
> the experience. I did not want to wait until someone else does this, instead 
> i wanted to tackle the problem by myself. My goal was to fix the regression 
> in 4.3.1 compared to 4.2 with minimal impact on existing code. Primary goal 
> was to change the existing design, behavior and code as little as possible. I 
> also tried to stick as accurately as possible to the naming scheme and the 
> coding style of the original authors.
> 
> I hope that you can understand my arguments and allow us to use Compiz 
> and KDE 4 together again.
> 
> Yours sincerely,
> WANA
> p.s. The corrected patch will follow later.
> 
> Aaron Seigo wrote:
> "The user should have the right and the freedom to decide for themselves"
> 
> they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms.
> 
> "Any other user does not have to deal with this option"
> 
> the developers deal with maintaining it, any bug reports that result from 
> it and users pay for that overhead indirectly. there is no such thing as a 
> patch that adds a feature that does no harm; the negative of more feature 
> weight must be offset by benefit. in this case, it also goes against some 
> design fundamentals.
> 
> it is therefore my decision that this patch which introduces a 
> purpose-specific hidden config option is not desirable to the upstream 
> project.
> 
> "My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal 
> impact on existing code."
> 
> it was coincidental that this worked in 4.2; it was not an intentional 
> feature.
> 
> "Primary goal was to change the existing design, behavior and code as 
> little as possible. I also tried to stick as accurately as possible to the 
> naming scheme and the coding style of the original authors."
> 
> i do appreciate that.
> 
> as Sebas noted on the mailing list, this really ought to be a property of 
> the wallpaper that the View can check. this would mean some new property in 
> Plasma::Wallpaper and a way to signal that it has changed so the view can 
> react if it wishes to. how to do that cleanly is the question. i don't think 
> Wallpaper should have something specific to this, but perhaps some sort of 
> properties system that can be set/changed by the Wallpaper (allowing us to 
> add things over time and keep the API straightforward from the start).
> 
> wearenotalone wrote:
> That sounds reasonable, but it is far too difficult for me. I will 
> continue to manually patch the Debian packages. If someone wants to use 4.3.1 
> with the wallpaper plugin, he will find all necessary information in the the 
> bug report. I will now discard this review request, ok?
>

"they do. they have the code. config options in software does not equate in any 
direct manner to rights or freedoms."

In my opinion, designing something around the code, i.e. setting all 
configurations in the source code is a design flaw as well. Sure people are 
free to modify the code, but that doesn't mean they can (permissions wise) or 
have the technical knowledge to.  I realize that kde likes to work with itself 
and that the plasma devs therefore would design plasma around kwin. As plasma 
is a desktop shell but not a window manager, it would be expected that it is 
possible to use other window managers/compositors together with plasma, and 
that plasma would give control to this other compositor/window manager to the 
furthest extent possible to allow for smooth interoperability. It should be 
noted

Re: New devicenotifier moved to kdereview

2009-10-05 Thread Aaron J. Seigo 
On October 4, 2009, Giulio Camuffo wrote:
> In data domenica 04 ottobre 2009 20:31:49, Aaron J. Seigo ha scritto:
> : > On October 4, 2009, Jacopo De Simoi wrote:
> : >
> > > On Sunday 04 October 2009 20:57:11 Aaron J. Seigo wrote:
> > > > On October 4, 2009, Jacopo De Simoi wrote:


> > consider two items, both with multiple actions and both of which have
> > been clicked to expand .. moving from the second action in the first
> > device to the first action in the second device would feel quite
> > "natural" and smooth if the ItemBackground moved between them.
> 
> well, actually you can't open two devices at a time, so if we keep this
>  behaviour the problem doesn't exist. on the other hand if we change that i
>  think it makes sense, even if i'd say it would introduce some complexity
>  in the code, but i'm not sure about that.

let me whip up a patch for you to look at and try :)

> > some other things that have come up as i've been using it today:
> >
> > * the popup icon only changes when the user will be notified of a device.
> > would it make sense to show an icon change even if the device is going to
> >  be ignored? that way there would at least be feedback that the applet
> > was aware there was a change and chose not to do anything about it?
> 
> what do you mean with "ignored", hidden?

sorry .. .yes, i meant "hidden".

> > * i really like how the unmounting waiting is shown; i did notice that
> > the icon overlay on a storage volume for mounted matches the action icon
> > to mount a device; but when you click on unmount, the overlay is a box
> > with a line through it. this seems asymmetrical. should the overlay on
> > the storage volume icon be the "unmount" icon?
> 
> the real problem there is that that icon to mount the device isn't the
>  right one. but there isn't an icon like "action-mount", so i had to
>  fallback to that.

ah, i see. so we need an emblem that works well for this. ok :) i'm talking 
with pinheiro about it. let's see what his artist's instincts come up with.

> > * there's a Plasma::IconWidget in DeviceNotifier; it never seems to
> >  actually be used. should it actually be the same as the icon in the
> >  NotifierDialog?
> 
> that's the icon shown in the panel

one might think so (that is initially what i thought it would be as well), but 
it's not as one can see from reading the code. here's the relevant code:

m_icon = new Plasma::IconWidget(KIcon("device-notifier",NULL), QString());
m_iconName = QString("device-notifier");

connect(m_dialog, SIGNAL(deviceSelected()), this, SLOT(showPopup()));

Plasma::ToolTipManager::self()->registerWidget(this);

setPopupIcon(m_icon->icon());

so m_icon is really a really complex way of storing a QIcon ;) i've fixed this 
in r1031628.

-- 
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: Review Request: Add an hidden option to set a translucent background for DesktopView

2009-10-05 Thread wearenotalone 


> On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > anything but the desktop shell painting the wallpaper is poor design. the 
> > window manager does not have enough knowledge of what is happening in the 
> > shell to do so properly. what, exactly, is the benefit of letting compiz 
> > draw the wallpaper? if it's simply visual bling, i'm really not interested 
> > in encouraging it by adapting plasma-desktop to such a broken idea.
> 
> wearenotalone wrote:
> Thanks for your feedback!
> 
> My intention was on the one hand to enhance the user experience for power 
> users and on the other hand to increase (respectively restore) the 
> compatibility with other applications like compiz. The user should have the 
> right and the freedom to decide for themselves. With this patch, the user is 
> able to use the wallpaper plugin of Compiz, if he really wants to. Any other 
> user does not have to deal with this option (because hidden), due to the 
> default setting "false" this may not cause any disadvantages / speed 
> penalties for him.
> 
> I use Compiz with multiple viewports; using the wallpaper plugin, I can 
> easily distinguish between different viewports. In addition, KDE4 looks 
> really great in cooperation with Compiz. To develop a proper mapping between 
> the viewports of Compiz and the desktop / activities of plasma, I simply lack 
> the experience. I did not want to wait until someone else does this, instead 
> i wanted to tackle the problem by myself. My goal was to fix the regression 
> in 4.3.1 compared to 4.2 with minimal impact on existing code. Primary goal 
> was to change the existing design, behavior and code as little as possible. I 
> also tried to stick as accurately as possible to the naming scheme and the 
> coding style of the original authors.
> 
> I hope that you can understand my arguments and allow us to use Compiz 
> and KDE 4 together again.
> 
> Yours sincerely,
> WANA
> p.s. The corrected patch will follow later.
> 
> Aaron Seigo wrote:
> "The user should have the right and the freedom to decide for themselves"
> 
> they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms.
> 
> "Any other user does not have to deal with this option"
> 
> the developers deal with maintaining it, any bug reports that result from 
> it and users pay for that overhead indirectly. there is no such thing as a 
> patch that adds a feature that does no harm; the negative of more feature 
> weight must be offset by benefit. in this case, it also goes against some 
> design fundamentals.
> 
> it is therefore my decision that this patch which introduces a 
> purpose-specific hidden config option is not desirable to the upstream 
> project.
> 
> "My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal 
> impact on existing code."
> 
> it was coincidental that this worked in 4.2; it was not an intentional 
> feature.
> 
> "Primary goal was to change the existing design, behavior and code as 
> little as possible. I also tried to stick as accurately as possible to the 
> naming scheme and the coding style of the original authors."
> 
> i do appreciate that.
> 
> as Sebas noted on the mailing list, this really ought to be a property of 
> the wallpaper that the View can check. this would mean some new property in 
> Plasma::Wallpaper and a way to signal that it has changed so the view can 
> react if it wishes to. how to do that cleanly is the question. i don't think 
> Wallpaper should have something specific to this, but perhaps some sort of 
> properties system that can be set/changed by the Wallpaper (allowing us to 
> add things over time and keep the API straightforward from the start).
> 
> wearenotalone wrote:
> That sounds reasonable, but it is far too difficult for me. I will 
> continue to manually patch the Debian packages. If someone wants to use 4.3.1 
> with the wallpaper plugin, he will find all necessary information in the the 
> bug report. I will now discard this review request, ok?
>
> 
> Nathanael Schilling wrote:
> "they do. they have the code. config options in software does not equate 
> in any direct manner to rights or freedoms."
> 
> In my opinion, designing something around the code, i.e. setting all 
> configurations in the source code is a design flaw as well. Sure people are 
> free to modify the code, but that doesn't mean they can (permissions wise) or 
> have the technical knowledge to.  I realize that kde likes to work with 
> itself and that the plasma devs therefore would design plasma around kwin. As 
> plasma is a desktop shell but not a window manager, it would be expected that 
> it is possible to use other window managers/compositors together with plasma, 
> and that plasma would give control to this other compositor/window manager to 
> the furthest extent

Re: Review Request: Add an hidden option to set a translucent background for DesktopView

2009-10-05 Thread Aaron J. Seigo 
On October 5, 2009, Nathanael Schilling wrote:
> > On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > > anything but the desktop shell painting the wallpaper is poor design.
> > > the window manager does not have enough knowledge of what is happening
> > > in the shell to do so properly. what, exactly, is the benefit of
> > > letting compiz draw the wallpaper? if it's simply visual bling, i'm
> > > really not interested in encouraging it by adapting plasma-desktop to
> > > such a broken idea.
> >
> > wearenotalone wrote:
> > Thanks for your feedback!
> >
> > My intention was on the one hand to enhance the user experience for
> > power users and on the other hand to increase (respectively restore) the
> > compatibility with other applications like compiz. The user should have
> > the right and the freedom to decide for themselves. With this patch, the
> > user is able to use the wallpaper plugin of Compiz, if he really wants
> > to. Any other user does not have to deal with this option (because
> > hidden), due to the default setting "false" this may not cause any
> > disadvantages / speed penalties for him.
> >
> > I use Compiz with multiple viewports; using the wallpaper plugin, I
> > can easily distinguish between different viewports. In addition, KDE4
> > looks really great in cooperation with Compiz. To develop a proper
> > mapping between the viewports of Compiz and the desktop / activities of
> > plasma, I simply lack the experience. I did not want to wait until
> > someone else does this, instead i wanted to tackle the problem by myself.
> > My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal
> > impact on existing code. Primary goal was to change the existing design,
> > behavior and code as little as possible. I also tried to stick as
> > accurately as possible to the naming scheme and the coding style of the
> > original authors.
> >
> > I hope that you can understand my arguments and allow us to use
> > Compiz and KDE 4 together again.
> >
> > Yours sincerely,
> > WANA
> > p.s. The corrected patch will follow later.
> >
> > Aaron Seigo wrote:
> > "The user should have the right and the freedom to decide for
> > themselves"
> >
> > they do. they have the code. config options in software does not
> > equate in any direct manner to rights or freedoms.
> >
> > "Any other user does not have to deal with this option"
> >
> > the developers deal with maintaining it, any bug reports that result
> > from it and users pay for that overhead indirectly. there is no such
> > thing as a patch that adds a feature that does no harm; the negative of
> > more feature weight must be offset by benefit. in this case, it also goes
> > against some design fundamentals.
> >
> > it is therefore my decision that this patch which introduces a
> > purpose-specific hidden config option is not desirable to the upstream
> > project.
> >
> > "My goal was to fix the regression in 4.3.1 compared to 4.2 with
> > minimal impact on existing code."
> >
> > it was coincidental that this worked in 4.2; it was not an
> > intentional feature.
> >
> > "Primary goal was to change the existing design, behavior and code as
> > little as possible. I also tried to stick as accurately as possible to
> > the naming scheme and the coding style of the original authors."
> >
> > i do appreciate that.
> >
> > as Sebas noted on the mailing list, this really ought to be a
> > property of the wallpaper that the View can check. this would mean some
> > new property in Plasma::Wallpaper and a way to signal that it has changed
> > so the view can react if it wishes to. how to do that cleanly is the
> > question. i don't think Wallpaper should have something specific to this,
> > but perhaps some sort of properties system that can be set/changed by the
> > Wallpaper (allowing us to add things over time and keep the API
> > straightforward from the start).
> >
> > wearenotalone wrote:
> > That sounds reasonable, but it is far too difficult for me. I will
> > continue to manually patch the Debian packages. If someone wants to use
> > 4.3.1 with the wallpaper plugin, he will find all necessary information
> > in the the bug report. I will now discard this review request, ok?
> 
> "they do. they have the code. config options in software does not equate in
>  any direct manner to rights or freedoms."
> 
> In my opinion, designing something around the code, i.e. setting all
>  configurations in the source code is a design flaw as well.

you misunderstand. the design as i am putting it down does not include this 
configuration option. others are free to disagree and change the source code 
to their desire. it has nothing to do with designing something around the 
code.

>  Sure people
>  are free to modify the code, but that doesn't mean they can (permissions
>  wise) or have the technical knowledge to. 

which isn't our problem. it is 100% INSANE to suggest that all things s

Re: Tokamak 4 dates

2009-10-05 Thread Shawn Starr 
On October 5, 2009 06:44:54 am Sebastian Kügler wrote:
> Hey fellow Plasmoids,
> 
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
>  around the openSuse offices. The next step to make it happen is finding a
>  date. From what I understand, the second half of February seems like a
>  good time. KDE 4.4 will be released beginning of February, so this would
>  fall nicely at the beginning of the 4.5 cycle.
> 
> So, how about we start on Feb. 19th and the last people depart on the 26th?
>  (That's Friday to Friday.)

If I am able to attend it could not be on the 19th, for those who know me will 
know why :(
> 
> Any other proposals for a date?
> 
> Also, who here would like to attend?
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Sebastian Kügler 
On Monday 05 October 2009 15:19:04 Jesus Sanchez Palencia F Filho wrote:
>  And these dates also are safe for the ones who intend to come to Bossa
>  Conference 2010 (March 7 - 10).

That's not entirely coincidental. :-)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Lukas Appelhans 
Hey!

I would like to attend as well (as you may know from the T3 talk :))... second 
half of February fits best for me as well...

I'll have to see if I can sort out to get me out of school for the week, if 
not I'd only be there at the weekend... :)

Lukas

Am Montag 05 Oktober 2009 12:48:46 schrieb Alessandro Diaferia:
> 2009/10/5 Sebastian Kügler 
> 
> > Hey fellow Plasmoids,
> >
> > As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
> > around the
> > openSuse offices. The next step to make it happen is finding a date. From
> > what I
> > understand, the second half of February seems like a good time. KDE 4.4
> > will be
> > released beginning of February, so this would fall nicely at the
> > beginning of the 4.5
> > cycle.
> >
> > So, how about we start on Feb. 19th and the last people depart on the
> > 26th? (That's
> > Friday to Friday.)
> >
> > Any other proposals for a date?
> >
> > Also, who here would like to attend?
> > --
> > sebas
> >
> > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> 
> I definitely would like to attend. I'm sorry for not having been much
>  around lately but i'm very busy with my last university exams :/ I hope
>  everything will be over by the end of december so that i can get back
>  working 100%. The second half of february seems more suitable for me too
>  :)
> Cheers
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Jesus Sanchez Palencia F Filho 
And these dates also are safe for the ones who intend to come to Bossa
Conference 2010 (March 7 - 10).

BTW, Call for Presentation is now open! http://www.bossaconference.indt.org/


cheers,
jeez

2009/10/5 Kenneth Christiansen 

> So do you guys need a WebKit guy around :-) ?
>
> Cheers,
> Kenneth
>
> On Mon, Oct 5, 2009 at 7:44 AM, Sebastian Kügler  wrote:
> > Hey fellow Plasmoids,
> >
> > As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
> around the
> > openSuse offices. The next step to make it happen is finding a date. From
> what I
> > understand, the second half of February seems like a good time. KDE 4.4
> will be
> > released beginning of February, so this would fall nicely at the
> beginning of the 4.5
> > cycle.
> >
> > So, how about we start on Feb. 19th and the last people depart on the
> 26th? (That's
> > Friday to Friday.)
> >
> > Any other proposals for a date?
> >
> > Also, who here would like to attend?
> > --
> > sebas
> >
> > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
>
>
>
> --
> Kenneth Rohde Christiansen
> Technical Lead / Software Engineer
> Qt Labs Americas, Nokia Technology Institute, INdT
> Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
> ___
> 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: Tokamak 4 dates

2009-10-05 Thread Kenneth Christiansen 
So do you guys need a WebKit guy around :-) ?

Cheers,
Kenneth

On Mon, Oct 5, 2009 at 7:44 AM, Sebastian Kügler  wrote:
> Hey fellow Plasmoids,
>
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in and around 
> the
> openSuse offices. The next step to make it happen is finding a date. From 
> what I
> understand, the second half of February seems like a good time. KDE 4.4 will 
> be
> released beginning of February, so this would fall nicely at the beginning of 
> the 4.5
> cycle.
>
> So, how about we start on Feb. 19th and the last people depart on the 26th? 
> (That's
> Friday to Friday.)
>
> Any other proposals for a date?
>
> Also, who here would like to attend?
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Kenneth Rohde Christiansen
Technical Lead / Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Frank Karlitschek 

On 05.10.2009, at 12:44, Sebastian Kügler wrote:

> Hey fellow Plasmoids,
>
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in  
> and around the
> openSuse offices. The next step to make it happen is finding a date.  
> From what I
> understand, the second half of February seems like a good time. KDE  
> 4.4 will be
> released beginning of February, so this would fall nicely at the  
> beginning of the 4.5
> cycle.
>
> So, how about we start on Feb. 19th and the last people depart on  
> the 26th? (That's
> Friday to Friday.)
>
> Any other proposals for a date?
>
> Also, who here would like to attend?
> -- 
> sebas
>


I would like to attend!

Cheers
Frank



--
Frank Karlitschek
karlitsc...@kde.org




___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Ana Cecília Martins Barbosa 
19th seems *great*, arthur! Perfect date. :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Qalculate plasmoid moved to kdeplasma-addons

2009-10-05 Thread Matteo Agostinelli 
On Wednesday 30 September 2009 19:29:29 Aaron J. Seigo wrote:
> On September 30, 2009, Matteo Agostinelli wrote:
> > Also, I would like to add that this is not meant to be a replacement of
> > the existing calculator but an optional "enhanced" calculator, since it
> > requires an additional external dependency (libqalculate). So IMO the
> > current choice of branding (name and icon) could be acceptable. If there
> 
> so i finally got it built and found some time to test it. some input:
> 
> * it uses QHttp; it must use KIO instead
> 
> * the network access in QalculateEngine::updateExchangeRates() is blocking
> rather than async
> 
> * there's nothing that defines the widget as being a calculator when it's
>  just sitting there. perhaps when there are no results the qalculate icon
>  could be painted in the results area? or even the icon and the name?
>  probably don't want to do anything with the line edit as it should have as
>  much space as possible
> 
> * minor issue: there's a tooltip even when the widget is shown fully on the
> desktop that probably isn't overly useful
> 
> >  are no objections, I would like to move it to kdeplasma-addons next
> >  weekend. I am willing to mantain it in the future.
> 
> i'm cool with this; the code looks good and if you are willing / able to
> maintain it -> win! :) i look forward to seeing this in plasma-addons for
>  4.4. do you have a checkout of kdebase around? if you do, could you put an
>  entry in workspace/plasma/design/CHANGELOG-4.4 for this? (if not, i can do
>  it for you)
> 
> btw, is libqalculate thread safe? if so, would you be interested in hooking
>  up qalculate to the calculator runner? if qalculate doesn't exist, it
>  could fall back to the current "evaluate it using qscript" method, but if
>  qalculate does exist it could get us a much nicer calculator runner.
> 
So, since all points have been addressed I have now moved the applet to 
kdeplasma-addons. I hope I did it properly. Let me know if there are some 
problems. Thanks!

Matteo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Artur Souza (MoRpHeUz) 
On Monday 05 October 2009, 07:44 Sebastian Kügler wrote:
> So, how about we start on Feb. 19th and the last people depart on the 26th?
>  (That's Friday to Friday.)

I'm so glad that you said those dates :) A friend of mine is marrying on the 
6th of February and Carnival is on the 13rd-17thso 19th seems good! hehe :)

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 4 dates

2009-10-05 Thread Marco Martin 
On Monday 05 October 2009, Sebastian Kügler wrote:
> Hey fellow Plasmoids,
>
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
> around the openSuse offices. The next step to make it happen is finding a
> date. From what I understand, the second half of February seems like a good
> time. KDE 4.4 will be released beginning of February, so this would fall
> nicely at the beginning of the 4.5 cycle.
>
> So, how about we start on Feb. 19th and the last people depart on the 26th?
> (That's Friday to Friday.)
>
> Any other proposals for a date?
>
> Also, who here would like to attend?

end of february sounds good to me.
as usual, any date, i'll do my best to be here :)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak 4 dates

2009-10-05 Thread Alessandro Diaferia 
2009/10/5 Sebastian Kügler 

> Hey fellow Plasmoids,
>
> As you've heard, Tokamak4 will take place in Nürnberg, Germany in and
> around the
> openSuse offices. The next step to make it happen is finding a date. From
> what I
> understand, the second half of February seems like a good time. KDE 4.4
> will be
> released beginning of February, so this would fall nicely at the beginning
> of the 4.5
> cycle.
>
> So, how about we start on Feb. 19th and the last people depart on the 26th?
> (That's
> Friday to Friday.)
>
> Any other proposals for a date?
>
> Also, who here would like to attend?
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

I definitely would like to attend. I'm sorry for not having been much around
lately but i'm very busy with my last university exams :/ I hope everything
will be over by the end of december so that i can get back working 100%. The
second half of february seems more suitable for me too :)
Cheers

-- 
Alessandro Diaferia
KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Tokamak 4 dates

2009-10-05 Thread Sebastian Kügler 
Hey fellow Plasmoids,

As you've heard, Tokamak4 will take place in Nürnberg, Germany in and around 
the 
openSuse offices. The next step to make it happen is finding a date. From what 
I 
understand, the second half of February seems like a good time. KDE 4.4 will be 
released beginning of February, so this would fall nicely at the beginning of 
the 4.5 
cycle.

So, how about we start on Feb. 19th and the last people depart on the 26th? 
(That's 
Friday to Friday.)

Any other proposals for a date?

Also, who here would like to attend?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel