[Panel-devel] Kickoff / KDE 4

Serhiy Veryovka 4bugzilla at gmail.com
Mon Oct 8 10:21:42 CEST 2007


Hello,

Please don't take my email as a try to start argument about Kickoff and
Raptor again. Actually I want to suggest the way how Kickoff and Raptor can
coexist and supplement each othe.

Actually Pinheiro's blog post is the first thibg that gives at least an idea
of what Raptor will be look like. And looking at this post (
http://pinheiro-kde.blogspot.com/2007/10/raptor-join-fun.html) I want to
explain my motivation.

From first sight Raptor looks for me as a Quicksilver for KDE. But
Quicksilver at the moment is far more advanced and powerful. I hope Raptor
will have same possibilities very soon.

Quicksilver will work for Mac OS because there is only one default
application to do something in Mac OS. I mean only one default player, one
default browser, one mail client, single IM application, etc. So if I do
"Play"->"Sound" in Mac OSX I definitely know that iTunes will be launched.
The same is for all other actions. But you know that Linux is absolutely
different story and especially KDE. In Linux you have a lot of application
which do the same (few browser, few mail application, etc). And what will be
if I do "Surf"->"Mail" in KDE? How do I make my favorite mail application to
be default? As far as I know Raptor can be configured in xml file. But you
can't force each user to edit xml file to customize his menu. I don't think
this is real. Besides menu users don't have any ide of what xml is.

As one of dissadvantages in the Raptor pdf file it is stated:
>Takes some time to find your application.
As I wrote previously in Linux you have a lot of application which do the
same. That is why the total number of installed application is huge. And
when you see only 5-6 apps icons on the menu panel it will not take "some"
time to find what you need. It will take ages! I think that because of this
reason there is a standardized list of menu categories at freedesktop.org (
http://standards.freedesktop.org/menu-spec/latest/apa.html). Categorization
makes it easier to find something. And I guess we can't deny this fact.

According the same pdf file main disadvantage of Raptor is
--
You have to know what you are looking for.
--
But what if you are a new user? Let's say you use Linux for the first time.
Or even if you use KDE 4 for the first time (this applies to everyone) how
you can exactly know what you are looking for? I mean there are new
applications. Or lets assume you've installed some aplication bunde. Let's
call it "KDE-ude". And you don't know what aplpications are included. And
you can't know what you are looking for. So the post comfortable way for you
to know what "edu" application you have is to open menu, navigate to the
corresponding category and see what you have. But with Raptor's single panel
layout how you can't do this? You will have to click on side arrows hundred
times to navigate you applications. Besides I am sure that new applications
from our example "edu" bundle will not be placed next to each other. There
will be some sorting.

That is why I don't think taht Raptor can be suitable menu for KDE users.

But please don't think that I am trying  to convince you that Raptor is
something bad. Raptor is a very good application but for a bit different
purpose.

My point is that Raptor can't be the start menu. Because it has absolutlly
different goal. It gives you convenient way to access applications when you
definitely know what you are looking for. That is why Raptor should be the
enhanced "Launch Application" applet. It will do this joob great.
But please don't try to push Raptor as a start menu. Because the start menu
is absolutely different thing.
What I suggest is to have a Kickoff as a default start menu. This menu has a
solid usability research behind it as is intuitively convinient for all
computer users. And especially for those who has
only Windows experience. And we should have Raptor as a powerful "Lauch
Application" applet. I guess that both applications can de default. But
because of conceptual differences the use cases of Kickoff and Raptor are
different. That is why Kickoff can be a menu in a its classical
understandning and Raptor can be an innovative "Lauch Application" applet.

Thanks for your attention,
--
Best regards
Serhiy

On 10/4/07, Riccardo Iaconelli <riccardo at kde.org> wrote:
>
> On Wednesday 26 September 2007 05:17:37 Robert Knight wrote:
> > Hi Riccardo,
> >
> > The simplest answer is that the Kickoff works, now.  The aim was to
> > have an implementation of a tried and tested design which could ship
> > with Beta 3.
> >
> > What I remember from the last IRC meeting and from talking to Siraj
> > was that Raptor was not going to be ready for the next beta
> > (originally due for tommorrow, now due next week).  I offered to
> > investigate Kickoff as a solution until then, and this is what I have
> > done.
>
> Ok, that's pretty good, thanks for the explanation, and thanks for having
> kept
> your answer under a rationale and calm tone. I would have understood you
> if
> you would have answered badly, as I wrote a very defensive e-mail, and I'm
> sorry for that.
>
> >
> > > (and given that kickoff has seems
> > > to have some technical problems, speed is the main complaint actually
> > > from the guys using opensuse).
> >
> > I did not discuss this in depth with others at Akademy although I have
> > heard Kickoff (KDE 3) described as "feeling heavy" in passing.  I
> > don't know exactly what the perceived problems are, but I get the
> > impression that they are implementation issues rather than a
> > fundamental design flaw.  I am happy to talk to OpenSuSE users and
> > developers for their opinions on the current Kickoff.
> > The big advantage here is that there are lots of users I can talk to
> > and seek opinions from.  There have been some small design changes
> > between the first version of Kickoff and the current version, and I
> > will look to incorporate those changes in the KDE 4 version.
> >
> > To clarify again though, this is not the KDE 3 code ported we are
> > talking about, but a from-scratch implementation with KDE 4 / Qt 4
> > frameworks.
>
> Thanks a lot for this explanation. Now it's much more clear to me about
> what's
> going on, it wasn't so clear before.
>
> As you said it in the mail beginning the thread, the kickoff rewrote
> looked
> (to me at least) like just a mere try to dismiss all the work that went on
> on
> raptor. And it sounded to me more like a personal attack to the raptor
> developers rather than everything else... that's why my answer was so much
> defensive. So, I'm sorry if I sounded agressive.
>
> So, now that I seem to have understood the whole thing, please correct me
> if
> I'm still wrong. You're just trying to make a menu basing on the kickoff
> experience, not to get rid of raptor, but just to be sure to have a
> functional menu for the next beta. =)
> Obviously, it also means having a chance of choosing the shipping menu for
> 4.0
> basing on the readiness of the projects, and without being forced to stick
> to
> one project. =)
>
> I'm really sorry if I reacted that way, I thought that it was a "pushing
> my
> pet project instead of helping the main thing", but as I already said I
> seem
> to have completely forgotten everything about a menu discussion, and I'm
> thinking that for next times logs are a good thing to keep. ;-)
>
> Thanks again for the explanation and I congratulate with you for your
> great
> work then. =)
>
> Bye,
> -Riccardo
> --
> GPG key:
> 3D0F6376
> When encrypting, please encrypt also for this subkey:
> 9EBD7FE1
> -----
> Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
> Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
> Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20071008/4e08e140/attachment.html 


More information about the Panel-devel mailing list