replace old kickoff with kickoff-qml

Review Request #106448 - Created Sept. 14, 2012 and discarded

Gregor Tätzner
I think it's time now to get the new kickoff into master so we can polish it for KDE 4.10. the qml plasmoid is still using the old model code (though slightly adjusted). This could cause issues for the c++ menu launcher "simpleapplet"...I'm not using it but actually it doesn't even compile. Probably would be better to port it to qml as well...opinions?

The qml code resides in the package dir. It's a pure qml widget with c++ model extensions...obviously :)

Add to Panel/Desktop is still not supported but overall I think we have reached feature parity with kickoff c++

I'm also worried about the upgrade path from kickoff-c++ to kickoff-qml. How can we ensure a smooth transition for devs and users?

not too much, surely have to update this diff a couple of times. But you can start dropping comments anyway.


  • 0
  • 3
  • 0
  • 3
Description From Last Updated
Daniel Nicoletti
Martin Flöser
Marco Martin
Kai Uwe Broulik
Richard Stockton
Richard Stockton
Richard Stockton
Albert Astals Cid
Gregor Tätzner
Review request changed

Status: Discarded

Change Summary:

This is sort of merged \o/
Marco Martin

there is an issue with it that came out only now with neon image that start with a clean environment:
default favorites are now completely lost, kickoff starts with an empty list

  1. The defaults should be set in the global kickoffrc file. It should be imported then (if a local kickoffrc has favourites, the should get loaded instead).

  2. Can you define "a local kickoffrc"? If multiple Kickoff instances can't have different favourites, it's a bug. Widget configuration is instance-local.

  3. As far as I see, kickoff in plasma 1 uses a kickoffrc file where it stores its favourites, and they are shared accross different instances of kickoff.

    We've had a lot of requests to make the favourites unified even accross different launchers (that is, I've had a lot of requests to make Kickoff and Lancelot favourites shared).

    Now we should switch to each instance has its own? If that is the case, there is no point in using activity manager for application<->activity linking. And the per-activity favorites patch should be reverted.

  4. p.s. Also ignore the review for kicker.

  5. This sounds like something we need a proper community-wide solution for me. My thinking is:

    • Plasma generally allows for multiple instances of the same widget with independent config, and breaking down those barriers is sort of a slippery slope that makes the system unpredictable for users ("if I change this, will it only affect this widget or all of them? I can't be sure").
    • Aside from making it unpredictable, it's also more restrictive - you lose the ability to use separate settings if you want them to be separate (in this concrete case, e.g. different favorites per monitor).
    • Allowing shared config requires widget authors to do much work work to implement things correctly (realtime synchronization).
    • Storing config outside the widget means that downstream customizers need to use two different ways to pre-configure widgets (desktop scripting for instance-local config, random rc files for other config).

    Specifically as far as launchers are concerned, as I mentioned on IRC, Marco and I have been talking on and off that we could use some sort of launcher framework to fix all the applet-specific interfaces we have right now.

    For example, Kicker has the application item context menu actions "Add to Panel", "Add to Task Manager" and "Add to Desktop". "Add to Task Manager" requires finding a Task Manager instance in the same containment and calling a function on it, and "Add to Desktop" behaves differently depending on whether the screen containment is a Folder instance (it will then all a function that creates a symlink) or not (it will then create an Icon applet instance, like "Add to Panel" does).

    All of this is highly desirable from an UX point of view - users want to do all of those - and it works, but it involves some hard-coded plugin identities.

    Now, if we do store launcher state somewhere central, though, then interested clients of that service still need to be able to select a subset of launchers to show, though, so that the specific launchers shown can be individual per instance.

  6. (Sorry, I meant "community-wide discussion to me".)

  7. Can you start a discussion on plasma-devel?