Decibel is a service that is concerned with real time communications; therefore, everything that connects one user with another user and makes it possible to get replies instantaneously is in the scope of Decibel. Decibel is based on the Telepathy D-Bus API’s and uses the Tapioca implementation of these API’s.
The Pillars of KDE 4: Decibel Definitions and Benefits
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I have to say, the KDE folks just seem to ‘get’ desktop integration. Everything is modularized and shared between applications in a very common sense way that makes you wonder how it can still be revolutionary (which it still is, in my opinion). There doesn’t seem to be much in the way of duplicated effort and replicated functionality…that kind of efficiency just makes me happy. Way to keep the dream alive.
Edited 2007-02-17 04:52
Agreed. This long-time GNOME user won’t be installing GNOME on any new systems. GNOME is fine, but KDE is really going for the optimal solution, and I respect that more than anything.
Agreed. This long-time GNOME user won’t be installing GNOME on any new systems. GNOME is fine, but KDE is really going for the optimal solution, and I respect that more than anything.
For the love of [ insert deity here ] can we please not have a GNOME vs. KDE flamewar every single time we post a desktop related article here?
Seriously. To some people your statement would be true, to others it would be false. Let’s just bury the unrelated opinions shall we?
I personally think it’s great to see stuff like this happening on *any* alternative desktop. Congratulations to the team.
For the record, Decibel is built on top of the Telepathy framework, a freedesktop.org framework written largely by GNOME developers. So, GNOME is likely to use Telepathy directly or with a GLib wrapper, whereas KDE will use Telepathy by wrapping it in a KDE friendly API through Decibel.
Both desktops are featuring integration. The main difference right now is that KDE is advertising it much more right now.
So, GNOME is likely to use Telepathy directly
While it might be possible that they are going to implement the whole Telepathy specification themselves, I think it is more plausible that they will also use an existing implementation, maybe even Tapioca (the one used by Decibel)
That is not correct.
The language bindings for telepathy that is recommended to KDE developers are actually those provided by Tapioca.
The telepathy website mentions a Mission Control component. It is not really clear what that is supposed to do and there is only a incomplete draft of it yet, but that is close to some of the things Decibel does.
Decibel is not a language binding, it is a service layer on top of telepathy.
Decibel is one of the least sexy yet most forward-thinking projects within KDE4. It’s hard to measure the impact it will have, because it offers new capabilities rather than just extra bling for the same applications we’re using today. Hopefully we’ll start to see applications embrace Decibel over the next couple of years and really deliver on the potential it promises.
It’s kind of sad that with all the work being done in things like Solid, Phonon, Akanodi and whatever used to be Tenor, that the majority of users are focused on Plasma. Not to take away from the great work that Aaron et al. are doing, along with the Oxygen team, but that’s really just the icing on the cake. I guess it’s just natural, given the instant-gratification GUI enhancements offer (show us the screenshots! show us the bling!), but I think the real story with KDE4 is with what’s going on behind the scenes, with the underpinnings and the frameworks. There’s just so much potential there.
Should also mention that, as been mentioned before, with all the hype around KDE4, that KDE 4.0 is likely going to disappoint if held up to that light alone. KDE 4.0 will lay the foundation and bring some cool new stuff, but it will be fascinating to see what comes through KDE 4.x.
Good point.
I think it would be very cool to integrate chat functionality in quite a lot of applications.
Not only would this enable working together on a document without any delays but it could also serve as a good help function. Imagine this:
You click “Help” and (along with FAQ) you get a button “support chat” where you can ask your question. If a question is asked over and over again it could be added to this (web based) FAQ.
You could probably even charge money for some of the chats, enabling new kinds of business opportunities with FOSS.
Another idea that comes to mind is to use this new functionality to simplify bug reports:
Enter the chat (after doing a quick search if the bug is already reported) and describe your problem.
The developer can then ask questions to get all the relevant information and finally put your bug report into the right category. I think this uncomplicated procedure would greatly increase the number of people who report bugs, as well as the quality of bug reports.
Looking forward to whatever version of KDE will implement this!
If they only clean up KDE 4, I’ll be happy. There is an overwhelming amount of programs in 3.5, quite a few of which have duplicate functionality.
Konqueror has way too many options and buttons, same with kdevelop that actually has duplicate tabs with practically identical functionality.
A desktop should be task oriented not program oriented. I don’t need 5 editors, I need an office editor and a programming editor (like kate, but with a usable interface) thats also good for .txt files. I also should not have to open programs blindly to find some specific functionality, because the program names don’t tell me anything.
I’m glad they are making leaps in technology, but if the technology is uncomfortable to use there is no point in developing it.
There is not a single program in KDE for which I could say has a nice interface.
I always did like Konsole and Kate, though Kate does have a few UI problems. I agree though, the main reason I use KDE is for the core components, not the apps at this point.
I forgot to mention K3b, which is an outstanding front end for cd/dvd burning.
There is an overwhelming amount of programs in 3.5, quite a few of which have duplicate functionality.
Tha amount of programs is only a effect of a mature and stable platform. The duplication of functionality is not that big. But you can say here are several areas of overlapping functionality, the reason wich is nicely ilistrad by your next comment.
A desktop should be task oriented not program oriented.
But you don’t get the gist of it, and misinterpret your understanding of the issue in your next sentence. It’s not an one size fits all world.
I don’t need 5 editors, I need an office editor and a programming editor
You seem to understand the different needs of different use cases, but you fail to see that others may have different usage patterns than yoursellf. And in the end you form a complaint based on the avalible tools for different users need, rather than simply analyzing your own needs and only install the right tools.
Personally I don’t compain that every Linux distribution include, if not in the default install at least on the disks, Emacs. An editor I haven’t used in 15 years, I simply don’t install it, or uninstall it when it annoys me. The same for KDE appications, the packages are designed to alow not install everything. And all the modern distributions split their binary packages, making it easy for the end users.
Edited 2007-02-17 11:51
nd in the end you form a complaint based on the avalible tools for different users need, rather than simply analyzing your own needs and only install the right tools.
Exactly!
Although, as a bit of defense for the poster you are replying to, some distributions do not offer the option of installing only needed tools or removing unneeded ones.
However, the possibility to approach the project producting the software often makes people forget that a different project/vendor is actually providing the software to them, and mistakenly complain to the producting project about problems the providing project is causing.
And in the end you form a complaint based on the avalible tools for different users need, rather than simply analyzing your own needs and only install the right tools.
The last time I installed a linux distro (last year I think) I did not have that much fine grained options. Or if I did it seemed like too much work to go through it all.
Once you become a professional developer and start dealing with clients, you quickly realize that they do not know exactly what they need. Just as I don’t know exactly what programs I would need if I were to install linux+KDE.
If I want to edit a HTML/PHP page, write a script, a C++ program, play music or a movie, download something with torrent, etc. I don’t want to think about what programs I need for this task, I just want the best program to be chosen automatically.
Stay out of the way when I don’t need them, show up when I want to perform some task. It’s not difficult, most tasks involve task specific files.
Choice is good up to a point, when it becomes cumbersome (quite quickly) it has a much more negative effect than if there wasn’t any choice at all. KDE has always had too much choice.
I don’t want a million programs that can all do the same thing, I want one good program.
Edited 2007-02-17 14:56
The last time I installed a linux distro (last year I think) I did not have that much fine grained options. Or if I did it seemed like too much work to go through it all.
Usually this is exactly the problem. The distribution chosen by a user has a target group the user does not belong to or has only partial overlap with the user’s goals.
Well, assuming for a moment that this kind of “as much as possible” packaging is actually having a target audience at all.
I just want the best program to be chosen automatically
Quite a number of distributions do this, i.e. assume that their choice of application for a task is the best for their users.
Choice is good up to a point, when it becomes cumbersome (quite quickly) it has a much more negative effect than if there wasn’t any choice at all
Yes, true. That’s why distributions targeting the mass market end user, e.g. Ubuntu/Kubuntu, Linspire, Xandros, provide a “best of breed” subset of available software, while distributions targeting the developers and the custom distributors, e.g. Debian, Fedora, OpenSUSE, provide the full range of available software.
KDE has always had too much choice
Fortunately for KDE and its users, the software provided by KDE’s developers is properly selected and packaged by the distributors before it reaches the users.
Properly meaning that the selection ending up in the user’s default installations is, depending on the target group, either a “best of breed” subset, or a wide range of options for those who like to apply their own selection rules.
This doesn’t imply that all users of a distribution have to be satisfied with the applied selection rules and packaging policies, but since they are as much a user like anyone else (in some cases even a customer), they should make their feedback available to those who decide about this polices.
Unfortunately there is often some kind of misunderstanding of the decision making process and complains about unfortunate packaging polices end up on KDE’s feedback channels instead of the distributor’s feedback channels.
Resulting in the users feeling that their feedback is not appreciated, KDE getting bad marks on something they have no control over and distributors not knowing that their policies cause their users trouble.
In the end I am always wondering why I am writing this, since experince shows that people rather keep barking up the wrong tree instead of learning how to provide feedback to the responsible entity.
“The last time I installed a linux distro (last year I think) I did not have that much fine grained options. Or if I did it seemed like too much work to go through it all.”
It would be nice to have at least an “hide / show” option for the installed application so the new user does not get overwhelmed with the amount of programs available. There could also be something like a metaport (from FreeBSD ports collection: a metaport is a control instance on top of “real” ports, which allow installation, deinstallation, compile etc.) for the most common KDE apps, e. g. kde-multimedia, kde-development, kde-office, kde-games… oh, I think this already exists.
“Once you become a professional developer and start dealing with clients, you quickly realize that they do not know exactly what they need.”
That’s right, I think KDE supports this status quo in offering the most functionalities (and therefore, applications) built in the basic install. This allows users who do not know what they want (or need) to work with the installed base applications; this may be useful especially if they do not own an Internet connection or the installation media to add other programs.
“Just as I don’t know exactly what programs I would need if I were to install linux+KDE.”
Needs usually develop in time. A set of applications installed by default could be fine the first weeks, but then you think, “Uh, now I want to burn a CD” or “I saw my son downloading this and that and making movies on the Internet, I want to do this as well.” At this point you have to know which applications serve the purpose you desire. In most cases, their pure names won’t tell you (e. g. Kaffeine = playing media files, K3B = creating and burning CDs / DVDs), only few do (Kmplayer = mplayer for KDE, Konsole = console / terminal emulator).
“If I want to edit a HTML/PHP page, write a script, a C++ program, play music or a movie, download something with torrent, etc. I don’t want to think about what programs I need for this task, I just want the best program to be chosen automatically.”
There is no “the best program”, because “best” depends on your intention. Always. For one user, Eclipse would be the best, for another, KDevelop would be. The default application for viewing images, KView, would not be the best for me (not my choice), I’d use something like xzgv -tzf, but that’s not a KDE application.
So, no application could be “choosen automatially”, there could only be a default or something like a hierarchy of defaults with a particular ranking, e. g. if Eclipse is installed, run it; if it’s not, run KDevelop instead.
“Stay out of the way when I don’t need them, show up when I want to perform some task. It’s not difficult, most tasks involve task specific files.”
Yes, file bindings (by extension or magic) could be a good starting point, but that’s not the end of the story, as I mentioned above.
“Choice is good up to a point, when it becomes cumbersome (quite quickly) it has a much more negative effect than if there wasn’t any choice at all.”
I like to introduce a concept which some of you (probably the older ones) might know. I liked the concept in Geoworks Ensemble. Because I did use the german version, I can’t promise my translations will be correct, but I’ll try anyway. Geoworks had a setting for complexity level that would affect the whole desktop or only a certain application. If you selected beginner, there were only few options. All basic tasks could be solved easily and quickly, more complicated means of work were hidden. If you got familiar with the basics, you could select advanced to show up more options. The menues got more content, the icon bars too, With the highest setting professional, all options were available.
This would be a nice approach for KDE, of course, as a modular concept, let’s call it Kontrolle (german for “control”), set user level: beginner, advanced, professional; effect all applications, affect only this application.
“KDE has always had too much choice.”
At first sight, yes.
When monitoring ex “Windows” users migrating to KDE (with no idea which OS was running) I noticed them complaining of having too much choice, having too much to configure manually before it fits their needs.
“I don’t want a million programs that can all do the same thing, I want one good program.”
This does not exist. “Good program” depends on intention. KDE cannot guess (and probably won’t) what you want to get finally. NB: The result of a task is in the center of ones interest, not the means to achieve this goal.
But in fact, I share your idea. I for myself install only the applications I want to use because I thik they are the best ones for the things I want to do. I’m sure you would choose another program for the same task. (For the record, I do not use KDE actively.) So I use Opera, X-Chat, Sylpheed, WindowMaker, xzgv, Midnight Commander, XMMS, Ethereal and all these stuff a KDE user surely would consider “outdated”, “geekish” or “useless”.
At this point, let me tell you what makes me upset when thinking about KDE. It does not integrate very well with non-KDE applications especially in regards of language. For example, if you install and setup PC-BSD with KDE and set “German”, KDE apps are in german, fine. You install Gimp and it is… not in german, it’s in english. And of course, the text mode consoles are still kbdmapped en_US (instead of de_DE) and do not support ISO-8859-1 charset. This is, of couse, not interesting for the new or even average user. But if X is not working due to changes of the GPU, you could be dropped down to the basics. Then, theres a prompt and here you go…
Furthermore, some of the multimedia functionalities need additional installs (codecs) and configuration (playing buffered and streaming media, embedded context etc.).
I like the idea of the kontrolle program (how about calling it ‘komplexity’?) except… how would you configure it?
Example: Xine-ui (which has horrible UI problems- the fonts are so big they overlap their own controls, but never mind) has several different layers of control complexity, from “Beginner” all the way up to “Master of the Known Universe”. Unfortunately for me, the controls I use most frequently are stuck under “Master of the Known Universe” (I think, xine-ui isn’t opening for some reason right now)
In short, what happens is I have to run in advanced mode so I can tweak what I need… probably defeating the purpose of the thing.
I’m only aware of three ways around this problem- one being all commands available all at once; another being a button marked ‘advanced’ that activates the advanced controls; the last one being the MS-Office style ‘most used toolbar items’ dynamically shrinking menus, which causes problems of its own when items switch positions.
I hope they figure out a way to separate these out well, so that people won’t have to run in advanced mode all the time, or won’t have to find everything based on where it is NOW versus earlier.
As for the integration thing, it seems like that kind of compatability with Gnome/GTK and KDE/QT applications is looming in the future… but for the average other program that does its own thing, short of a massive adherance to LSB and/or Freedesktop.org standards I don’t think the problem’s going to be solved, and certainly not by KDE (unless they somehow develop a library to do nothing but go in and tweak every toolkit’s language setting, assuming it has one)
“I like the idea of the kontrolle program (how about calling it ‘komplexity’?) except… how would you configure it?”
Never ask me how I would configure something; I’d surely answer: “Setting is: Enable all options, don’t annoy me anymore, I know what I’m doing, I do this stuff since the 70s!”
But honestly, there is another way. As it was mentioned before, the different Linux and BSD distributions all have their specific audiences. So instead of trying to determine which settings, applications and options are the “best” ones, let the user decide which distribution fits his needs best.
Komplexity sounds good. Complex city, Kornflakes city… okay, let’s leave SILLY_MODE for now.
“In short, what happens is I have to run in advanced mode so I can tweak what I need… probably defeating the purpose of the thing.”
There could be another mode (next to “beginner” (BM), “advanced” (AM) and “professional” (PM)), let’s call it “individual mode” (IM). In this mode, the user could select the items he uses most, and then they will be included in the menues, not matter if the respective item belongs to BM, AM or PM. If the user switches from IM to BM, his IM settings won’t change.
“I’m only aware of three ways around this problem- one being all commands available all at once; another being a button marked ‘advanced’ that activates the advanced controls; the last one being the MS-Office style ‘most used toolbar items’ dynamically shrinking menus, which causes problems of its own when items switch positions.”
The problem of the dynamical subset determination would be a situation like this: A user does not use a certain option for a longer time, so it disappears. But then, he needs it and can’t find it anymore.
“I hope they figure out a way to separate these out well, so that people won’t have to run in advanced mode all the time, or won’t have to find everything based on where it is NOW versus earlier.”
I agree.
“As for the integration thing, it seems like that kind of compatability with Gnome/GTK and KDE/QT applications is looming in the future… but for the average other program that does its own thing, short of a massive adherance to LSB and/or Freedesktop.org standards I don’t think the problem’s going to be solved, and certainly not by KDE (unless they somehow develop a library to do nothing but go in and tweak every toolkit’s language setting, assuming it has one)”
There are some environment variables that control the language of many Gtk and neither-KDE-nor-Gtk applications.
setenv LC_ALL de_DE.ISO8859-15
The variables LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and LC_TIME even allow a finer tuning. They affect some text mode applications as well (see GNU gettext).
But this does not affect the keyboard language (layout)! While KDE does this on its own, non KDE applications might rely on the settings provided by Xorg’s configuration or the absense of it.
Section “InputDevice”
Identifier “Keyboard0”
Driver “keyboard”
Option “XkbModel” “pc105”
Option “XkbLayout” “de”
EndSection
Still, this does not affect keyboard layout in text mode (see kbdmap)…
I did not have that much fine grained options. Or if I did it seemed like too much work to go through it all.
Both those issues are distribution related, nothing too do with KDE. All modern distributions split the KDE packages to some extent, and have for some years now. If the package selection does not fit your need it’s perhaps because you is not considered the target audience for the distribution, or the distribution has plainly not done a good job.
I don’t want a million programs that can all do the same thing, I want one good program.
Here your logic is flawed. You don’t consider the nature of the task. Even if they sometimes share the same basic requirements, they are not the same. So there can not be one good program.
A good example are applications able to edit text, for instance in KDE 3 you can use KWrite, KEdit, Kate, Kdevelop or Quanta. But they are not the same, they have widely varying scope and use cases. And that big variation in usage pattern is the reason none of them can be the one good program. You can write your 100k lines C++ program with KWrite, or do a quick change to your .profile file with Quanta. But neither are well suited to the tasks, nor are they intended to be.
Well, as you probably know, it’s on the agenda. Some work is already done (there are two editors now, Kate, which is a light development environment with session support, build in konsole, advanced plugins etc, and kwrite, which is your basic (but still powerfull) editor. Kedit is gone, it was still in KDE because it was the only editor with support for bi-directional text editing… And kword, well, isn’t that a whole different category?
The latest KDevelop 3.4 already got some cleanup and I’m sure more is to follow, and for Konqueror a lot is going on.
Anyway, I do know some KDE apps with a good and clean interface – Codeine comes to mind, and Amarok isn’t that complex if you compare it with applications with equal functionality (those don’t exist so just double the amount of interface elements in the most advanced competitors…)
Well, as you probably know, it’s on the agenda. Some work is already done (there are two editors now, Kate, which is a light development environment with session support, build in konsole, advanced plugins etc, and kwrite, which is your basic (but still powerfull) editor. Kedit is gone, it was still in KDE because it was the only editor with support for bi-directional text editing… And kword, well, isn’t that a whole different category?
The better solution would be to have one editor (KWord isn’t an editor, its a wordprocessor) and use plugin functionality to expand its abilities rather than creating a seperate application entirely.
> > there are two editors now, Kate, which is a light
> > development environment with session support,
> > build in konsole, advanced plugins etc, and
> > kwrite, which is your basic (but still powerfull) editor.
> The better solution would be to have one editor
> and use plugin functionality to expand its
> abilities rather than creating a seperate application entirely.
Funny you should mention that. The KDE devs have built a time machine and granted your wish: Kate and kwrite *are* the same code.
As to the rest (just to sum up what has been mentioned above):
– kedit is a legacy app that was still needed for bidi users
(no longer in KDE4 though, IIUC kate/kwrite supports bidi there)
– everyone seems to agree that KWord is in a completely different category.
Case closed.
let me guess, kate basically wraps kwrite with a whole host of other kpart tools?
same that they did with the calendar and contacts programs, build another program that wrapped both of them into a single gui.
now if anything shows of the power of kparts, that does
now, with decibel and maybe some kind of VB style RAD environment (im not that handy with c(++)), i can see a way to wrap it all up into a outlook killer
a single unified control center for all you communication needs
just needs a exchange like back end. was there not some work being done on that for the german government?
It’s quite amazing to see how much kde has changed over the two last years with respect to PR. I think everyone will agree that they were kinda under-marketed in the 3.x series but lately they have really done a lot to involve the community (which I’m sure also brings along more developers), something that is especially important in a time like this when big releases are far apart.
Stuff like `This week in SVN`, `Pillars of KDE`, `The Road to KDE 4` as well as developer interviews really make a big difference (dot.kde.org)
When you perform the obligatory comparison with gnome you could say that they have gone the opposite direction. E.g. where are these http://www.gnome.org/~davyd/gnome-2-14/ for 2.16 and 2.18?
I would have to agree with what ‘elsewhere’ said, kde 4.0 will most likely disappoint after all this marketing/hype, but it will surely lay an avesome fundament for innovation throughout the 4-series.
Edited 2007-02-17 10:32
There have indeed been changes. I think it’s really due to a shift in thinking in the KDE project. I’ve even heard developers say ‘we need non-coders more than coders’ – now that’s really something for such a technical-focused project like KDE
It might also be due to the nature and composition of the community. I’m not sure KDE is larger (even tough it has a larger userbase) but KDE does have more volunteers (70%) compared to Gnome (30%) and that probably shows in PR lately? Community is crucial for a FOSS project, after all.
Though many will not admit it, I think a lot more info. has been forthcoming since Thom’s articles criticising the future of the KDE (and Gnome) projects.
So while his articles were poorly received (and some would argue, rightfully so), I think they have indeed produced a lot more openness from the KDE project if nothing else. Now I hope we hear more from the Gnome camp.
//Though many will not admit it, I think a lot more info. has been forthcoming since Thom’s articles criticising the future of the KDE (and Gnome) projects.
So while his articles were poorly received (and some would argue, rightfully so), I think they have indeed produced a lot more openness from the KDE project if nothing else. Now I hope we hear more from the Gnome camp.//
I have to concur here.
From an absolute dearth of information some while ago, we are now hearing at least some regular information about KDE4. I think OSAlert’ prompting had no small part to play in that.
I think that Thom’s article got the ball rolling with new information releases for whatever reason. Maybe it was just a coincidence, but I don’t believe that much in coincidence.
Also whatever happened to Tenor? Has it been axed or what? Is KDE going to have an answer to spotlight or Beagle?
I think Strigi is the new search tool.
Telepathy, Tapioca, and in some comments now Solid, Phonon, Akanodi, Plasma, Oxygen. I don’t understand the language of KDE it seems…
Some few more sentences explaining the terms would improve the newposts and comments about KDE alot…
How about using google; throw Telepathy KDE into google and voila: http://telepathy.freedesktop.org/wiki/FrontPage
It feels like they are using the words Microsoft used to create the hype around Longhorn/Vista technologies.
“The Pillars of KDE4” …hey!
just that unlike vista, KDE will not be trowing away features to hit some launch date
are we still hoping for a August’ish release of kde4?
All these keywords are for new KDE technologies and frameworks of KDE release 4.
Decibel (communications framework), Plasma (UI framework), Oxygen (art/icons overhaul), Phonon (multimedia framework), Solid (hardware interface and abstraction framework), D-Bus (IPC [Inter-Process Communications] framework).
These technologies will make KDE programs easier to develop, nicer looking, faster, more featureful, smarter, and able to inter operate with GNOME applications much better.
You can read more about them on the KDE website, http://www.kde.org
I don’t hold my breath to much in the ussabilty department after seen this screenshot:
http://vizzzion.org/images/blog/powermanager-feisty.png
Thekde power manager have the next flaws in my opinion, not a flame, just a couple of observations.
1.- There’s no need to put the CPU informartion in the power manager because there is an applet that can do that already, when I want to know the energy left I don’t need to know my cpu information because I already know it, just waste space.
2.- The cpu clock is represented by a progresbar, that’s a bad option you are not measuring the cpu againts anything or in the middle of a process so why a progressbar?
I don’t know if this is the way it will be in KDE4 but I hope not.
The progress bar is reporting the speed the cpu is CURRENTLY running at, 1000 mhz in the screenshot, which is approx half the max speed (2 ghz). So you can see if your cpu is running full-speed or less. Now that might not be extremely interesting all the time, but I wouldn’t call the tooltip crowded with information yet… At least you can see if you’re stressing the CPU much, or if it’s saving energy by using a lower speed.
The screenshot shows the guidance-power-manager developed for kubuntu.
AFAIK that is not related to KDE and a placeholder till an updated kpowersave is available that does not depend on its own daemon.
I can’t wait for it, bring it on