Re: Review Request: Timer: one click to pause/resume, blinks when paused.

[Aaron J. Seigo]

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


good ideas; a suggestion for improvement: instead of just showing/hiding items, 
why not use a QPropertyAnimation connected to a Q_PROPERTY in the applet that 
sets the the opacity of the items so they fade in/out? it would probably look a 
lot more slick.


applets/timer/timer.h


watch the indentation :)



applets/timer/timer.cpp


you need to check if event->pos() is inside geometry()

also, whitespace around curly braces :)



applets/timer/timer.cpp


instead of a jumble of letters like tsvgw, consider using something "plain" 
like "widget"



applets/timer/timer.cpp


must simpler as:

widget->setVisible(!widget->isVisible());



applets/timer/timer.cpp


should be on same line


- Aaron J.


On Feb. 2, 2011, 4:25 a.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100521/
> ---
> 
> (Updated Feb. 2, 2011, 4:25 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch does some little changes to Timer plasmoid:
>  - Now it takes only one click to start, resume and pause it
>  - It now blinks when paused, making it quicker to determine if it's paused 
> or running
>  - Double-click resets timer
> 
> 
> Diffs
> -
> 
>   applets/timer/timer.h d191fa3 
>   applets/timer/timer.cpp a09aa4c 
> 
> Diff: http://git.reviewboard.kde.org/r/100521/diff
> 
> 
> Testing
> ---
> 
> As it's a simple modification, I think that it brings no bugs (except by the 
> fact that it says timeout when reseted with double-click).
> 
> 
> Thanks,
> 
> Romário
> 
>

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

Review Request: Timer: one click to pause/resume, blinks when paused.

[Romário Rios]

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

Review request for Plasma.


Summary
---

This patch does some little changes to Timer plasmoid:
 - Now it takes only one click to start, resume and pause it
 - It now blinks when paused, making it quicker to determine if it's paused or 
running
 - Double-click resets timer


Diffs
-

  applets/timer/timer.h d191fa3 
  applets/timer/timer.cpp a09aa4c 

Diff: http://git.reviewboard.kde.org/r/100521/diff


Testing
---

As it's a simple modification, I think that it brings no bugs (except by the 
fact that it says timeout when reseted with double-click).


Thanks,

Romário

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

feature/topic branches; activities runner

[Aaron J. Seigo]

hi all...

huzzah for the new git, huh? ok.. so ... feature branches. there is going to 
be an irc meeting, probably the weekend after next, about the workflow for 
kdelibs and kde-runtime. i hope we will be able to use that for kde-workspace 
as well.

in any case, i just pushed a new feature branch to kde-workspace: 
aseigo/activityrunner ... just as Martin did with the kwin branches, i've 
prefaced them with my commit account so it is easy to see who is responsible 
for it. if there are multiple people who are collaborating on a branch from 
the start, we'll have to come up with something better/different i guess :)

as you might guess, aseigo/activityrunner has an activities runner in 
plasma/generic/runners/activities. and it basically works:

"activity" (or the i18n of that) lists all activities
"activity " will start to match activities by name

i can imagine other possible features (removal? renaming? creation?) but i'd 
rather start with this. code review is welcome and desired. i'll put it up for 
"kde review" shortly once others have tried it and feature scope definition 
handled.

note that i also had to make a small change to KActivityConsumer, to fully 
scope the name of the enum in the signal so it is reasonably easy to connect 
to.

p.s. why an activities runner? why, as part of the "make activity features 
ubiquitous" goal for 4.7 :)

-- 
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: the next step on the desktop

[Markus Slopianka]

Am Dienstag 01 Februar 2011, 13:17:51 schrieb Sebastian Kügler:

> Actually, Aaron expressed my thoughts about your comments exactly.

If that's the case, you guys really should work on your self esteem. Just 
because someone 
tells his opinion he certainly does not necessarily demand his opinion to turn 
into 
reality as if you guys were his slaves.
My initial mail does not contain a single word of harsh language or a demand of 
any kind.
OTOH Aaron's mail implied lots of negative stuff about me that cannot be 
farther from the 
truth.


> It's not
> about calming down, but about having a useful discussion among Plasma
> developers. People don't just take part to advance their own agenda, we're
> having this discussion to determine direction.

I stand by my opinion that turning the focus towards Activities benefits mostly 
the kind 
of user who uses many applications simultaneously. If you agree: Fine. If not: 
The world 
doesn't collapse either.
I never have and never will bitch about defaults that may not suit my taste, 
just as I 
never bitched about my Plasma Netbook mockup from a few months ago not being 
received 
well.

Believe it or not: Whatever you will come up with, I'll stay grateful for your 
work.

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

Re: Automatic activity switching and other stuff -- thoughts for 4.7

[Aaron J. Seigo]

On Tuesday, February 1, 2011, todd rme wrote:
> either triggers or at least prompts a switch to a particular activity.

"triggers" is the operative word here; imho, kactivitymanagerd (KAMD) ought to 
accept requests for activity changes. the requests should probably include:

* the name of the activity to trigger
* a (translated) reason for the trigger
* the source of the trigger
* a weighting for the triggger?

KAMD should return an id to track the request with, and should batch the 
requests up to avoid flooding the user with a constant barrage.

the most recent (and/or most highly weighted?) trigger should be shown to the 
user via the notification system. the user could interact with the 
notification to approve the switch or ignore it.

if the application that requests the trigger changes its mind, it can cancel 
the trigger request with the id.

KAMD could perhaps even hold an internal "stack" of activities, allowing an 
app to trigger an activity and then "untrigger" it, returning the user to the 
previous activity. this could be useful for transient triggerings, such as the 
IM example.

Ivan: what do you think?

-- 
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: the next step on the desktop

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Marco Martin wrote:
> (seems even a good jj that someone starting with plasma could do, please
> put it into the wiki)

by which Marco means this page: http://community.kde.org/Plasma/Tasks

-- 
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: the next step on the desktop

[Marco Martin]

On Tuesday 01 February 2011, todd rme wrote:
> 
> Oh yes, another idea someone had that I forgot to mention: automatic
> runner focus.  In other words, when focus is on the desktop (or there
> are no windows visible), and you start typing, automatically pull up
> krunner and enter the text there.
> 

i like the idea.
maybe the containment action plugins must be expanded to support keypress 
events too ;)

(seems even a good jj that someone starting with plasma could do, please put 
it into the wiki)

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

Re: the next step on the desktop

[Jeffery MacEachern]

On Tue, Feb 1, 2011 at 04:40, Marco Martin  wrote:
> On Tuesday 01 February 2011, Dario Freddi wrote:
>> Aaron, thanks for putting this to attention. I want to add some other
>> points which are relevant to me and I think fit well into this context.
>> Sorry for not replying to other points, but I see a lot of enthusiasm,
>> which is awesome, but also translates to: too much text :D
>>
>> However, preamble: these days I'm using Mac OS for some tasks, and while I
>> am proud about missing a LOT of stuff from KDE, and think KDE is overall
>> better, I have found myself missing some small things in Mac OS.
>>
>> The very first one is: multitouch gestures on the touchpad. In Mac OS,
>> using a four-finger swipe triggers present window or show desktop,
>> depending on the direction of the swipe. This is a TOTAL game changer in
>> usability imo, as you are able to access windows or desktop through a
>> single gesture. I think this would be a great target and rather simple to
>> implement, given that the underlying architecture is ready - maybe
>> somebody else can comment on that.
>
> It (as usual) all depends fro the hardware support i fear :/

I think you're right, but I know I've previously used at least one
(non-Mac) laptop that supported multi-finger tap and swipe, although
nothing fancier like pinch or such.

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

Re: the next step on the desktop

[todd rme]

On Sun, Jan 30, 2011 at 10:00 PM, todd rme  wrote:
> On Sun, Jan 30, 2011 at 8:22 PM, Aaron J. Seigo  wrote:
>> hi...
>>
>> back when we started the path towards plasma i said that we needed to slowly
>> evolve the desktop beyond the desktop folder with icons littered on the
>> desktop.
>>
>> now we have activities, kick-ass containments like search and launch and
>> grouping desktop.
>>
>> it is time to go to that next step and move people away from the old ways.
>>
>> i was at a friend's house last night where a bunch of people gathered to hang
>> out, chat, play games, etc. there was a desktop system there running plasma
>> desktop with the search and launch containment and a gorgeous translucent
>> panel couresty of kwin.
>>
>> i saw it and hardly recognized it: it looked new, amazing, the next thing. it
>> looked amazing.
>>
>> so, here's my suggestion for 4.7:
>>
>> let's try something big and new. let's make that Big Move and step away from
>> ~/Desktop.
>>
>> my proposal is this:
>
> I have some extensions to this, more blue-sky and not necessarily feasible:
>
>> * by default, Search and Launch on the desktop
>> * an icon in this S&L that takes you to your desktop folder .. in a file
>> manager.
>
> I think this is potentially a good idea, but I think as it currently
> stands it denigrates the importance of widgets on the desktop.
>
> My suggestions would be:
> 1. Break the S&L containment into categories.  Applications,
> bookmarks, and contacts already exist.  Add some additional
> categories: places, devices, and widgets come to mind.  These would
> all be kio slaves under the hood.  Places would allow you to navigate
> the file system from within the S&L interface, devices would show
> removable devices and let you manage and browse them, and widgets
> would let you launch individual plasma widgets within the S&L
> interface.  Individual items and categories from all of these could be
> dragged to the favorites at the top, and individual categories can be
> turned on and off.  Clicking on a category or sub-category in the
> favorites would jump straight to it.
>
> 2. Add breadcrumb navigation next to the "back" button to make it easy
> to get back to specific levels.
>
> 3. Let users resize the favorites bar and add widgets to it.  Widgets
> will take the panel form-factor, but if the favorites bar is sized
> large enough they should switch to the desktop form-factor (as they
> are supposed to do on existing panels).  The favorites bar can scroll
> if you put too much in it.
>
>
>> * a new panel layout (TBD: let's work on this together!)
>> * improve the tasks widget to have some of the nice features of widgets like
>> "smooth tasks" with the mouse over highlights
>
> Some other possible improvements:
> - Application control interfaces moved from the system tray to the
> task manager (I recall you mentioning this before).
> - More focus on thumbnails.  For instance smooth tasks lets you close
> applications from the thumbnails.  There should also be prettier ways
> to deal with groups with large numbers members
> - I think it would be nice if applications had some way to extend the
> thumbnail display.  For instance put buttons on it, or have a pop-up
> button to show extra thumbnails (such as thumbnails of tabs you can
> select).  This may not be feasible using existing desktop standards,
> though.
>
>> * an "activities" widget (i'll hapilly write it) that sits next to the app
>> launcher and when clicked brings up the actvities manager
> You mean like this:
> http://kde-look.org/content/show.php/Activity+Manager+Plasmoid?content=136278
>
> Also, if we are going with S&L, having a list of activities available
> within the S&L interface would probably be a good idea, especially if
> you are intending it to be a jumping-off point for other activities.
>
>> * an activities switcher as a kwin effect (!)
> See here:
> http://forum.kde.org/brainstorm.php#idea90912
>
>
>> * have all activities avaiable in kactivitmanagerd, even if they are 
>> "stopped"
>> in plasma-desktop
>>
>> thoughts?
>
> - Why are you restricting it to one panel?  Having several panels by
> default with different sizes and shapes for different sets of items
> might be at least worth considering.
>
> - It might be worth looking into merging the pager and activity
> manager.  A side benefit might be that we can get thumbnails on hover
> with the pager.
>
> - It might be worth re-visiting whether the current default
> application launcher is optimal.  Launchers like lancelot and raptor
> have some interesting ideas, and I have seen some other ideas batted
> around as well (such as an application launcher using a grid view
> instead of a list view).
>
> - If you are looking for appearance ideas, this has some interesting
> ones: http://icey-net.deviantart.com/art/Ubuntu-Concept-Design-FULL-158871634
> Some stuff is good, some stuff isn't as good, but it might be helpful.
>  I especially like the lights underneath the applications i

Re: Automatic activity switching and other stuff -- thoughts for 4.7

[todd rme]

On Sun, Dec 19, 2010 at 3:49 AM, Ryan Rix  wrote:
> Hey all,
>
> Long mail follows, sorry. Really only of interest to Chani, Aaron, Ivan and
> other activity folks... :)
>
> My goal was to bring this up for 4.6 but herp derp, I didn't, so here we go.
>
> I've been thinking a lot about how to give the Activity Manager a way to
> predict what a user would like to be doing at a certain time, based on
> external input, whether that's things like current GPS coordinates, what is
> scheduled in KOrganizer right now, etc. What follows is a braindump of crap
> I've been contemplating since before akademy, and it may well not make any
> sense.
>
> Basically, I'm trying to answer a simple question: "what would cause a user to
> change what they are doing (their activity), and can we monitor those events
> to facilitate this change for them?":
>
> Susan tags her workplace in Marble (or wherever) with the Nepomuk tag "work".
> The manager tracks Susan's current location via the Plasma geolocation
> dataengine and when it detects that Susan has arrived at work, changes the
> current activity to the activity associated with the "work" Nepomuk tag.
>
> Terrance has different activities for each of his university courses. When he
> adds homework assignments or adds his class schedule to KOrganizer, he tags
> each event with the specified class, as well as asking the manager to switch
> to the associated activity when the event occurs. When the event occurs, the
> manager automatically switches to the activity associated with the Nepomuk tag
> Terrance has associated with the event.
>
> etc... Makes sense, no? I have some other use cases, but I won't copypasta
> them here, for sanity's sake.
>
> There is also the choice of making something like this wider than this,
> controlling notifications status ("presentation mode"), etc... All of this
> falls in to this sort of "predict what the user wants to do" idea, but not so
> much with Activities as we know them.
>
> So, basically we end up with two things:
> * What would cause a user to change what they are doing?
> * How would they change what they are doing?
>
> So, we end up with two lists of "things" -- plugins. What kind of API should
> these plugins be expected to have and what should they expect to be able to
> do?
>
> Then comes the question of how to implement something like this Fun. Do we
> do it in kactivitymanagerd? In its own daemon? kded plugin?
>
> Next, where are we with the symbiosis between Nepomuk and the Activities
> infrastructure? Both of the usecases I described above use Nepomuk tags; they
> don't have to, but it's a decision we'd have to make before jumping in to
> writing some code like this -- do we use Nepomuk tags, or do we hardcode to
> Activities or whatever resource the plugin manipulates...?
>
> I'd like to start a dialog on this, and have something to show for 4.7 this
> time around. I've pissed around on this for nearly six months, and have a lot
> of nice ideas, just need to see how viable they are and how much they make
> sense.
>
> Lots of love,
> Ryan

I think people should also be able to tag files and folders with
activities, so opening that file or a file in a particular folders
either triggers or at least prompts a switch to a particular activity.
 Tagging contacts with activities would probably also be useful, so if
you start a chat with someone or open an attachment from someone it
prompts you to change the activity (although these are definitely
situations where it should NOT happen automatically).

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

Re: kdeplasma-addons is on git

[Marco Martin]

On Tuesday 01 February 2011, Artur de Souza wrote:
> Hello!
> 
> I would like to inform that the move of kdeplasma-addons to git and
> completed successfully.
> Now you can find the new repository in:
> 
> git clone git://anongit.kde.org/kdeplasma-addons
> 
> Thanks a lot to eean for the help and to our awesome sysadmins.
> 

you're the man :D

(and also everybody involved in all other migrations ;))

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

kdeplasma-addons is on git

[Artur de Souza]

Hello!

I would like to inform that the move of kdeplasma-addons to git and  
completed successfully.
Now you can find the new repository in:

git clone git://anongit.kde.org/kdeplasma-addons

Thanks a lot to eean for the help and to our awesome sysadmins.

Cheers,

Artur


---


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

Re: roadmap of the chime feature in the analog clock

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Steven Sroka wrote:
> I don't know if this falls under the category of
> "nice-to-have-but-rarely-used" but could there be an option available
> that allows chimes to be disabled if the computer is actively being
> used (eg. there are mouse clicks or keyboard button presses or a movie
> is being played, etc).

i think this only makes sense for situations such as "watching a movie" or 
"doing a presentation in front of a crowd", in which case we'd be far better 
off extending and using KNotificationRestrictions.

-- 
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: the next step on the desktop

[Martin Gräßlin]

On Tuesday 01 February 2011 13:07:58 Dario Freddi wrote:
> Aaron, thanks for putting this to attention. I want to add some other
> points which are relevant to me and I think fit well into this context.
> Sorry for not replying to other points, but I see a lot of enthusiasm,
> which is awesome, but also translates to: too much text :D
> 
> However, preamble: these days I'm using Mac OS for some tasks, and while I
> am proud about missing a LOT of stuff from KDE, and think KDE is overall
> better, I have found myself missing some small things in Mac OS.
> 
> The very first one is: multitouch gestures on the touchpad. In Mac OS,
> using a four-finger swipe triggers present window or show desktop,
> depending on the direction of the swipe. This is a TOTAL game changer in
> usability imo, as you are able to access windows or desktop through a
> single gesture. I think this would be a great target and rather simple to
> implement, given that the underlying architecture is ready - maybe
> somebody else can comment on that.
I am a trackpad user and wanted to have the swipe to alt+tab and present 
windows since I first tried it. If the underlying stack is there, adding to 
present windows is something like connecting one signal. Tabbox is a little 
bit more difficult as it currently requires to keep alt (or any other 
modifier) pressed. But should also be solvable and I would like to see it (not 
only for this featue)

Cheers
Martin


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: the next step on the desktop: Improving Activities UI

[Martin Gräßlin]

On Tuesday 01 February 2011 13:45:14 Sebastian Kügler wrote:
> - Making KWin's taskswitcher more Activity-aware, for example by grouping
>   windows in the Boxswitch, by having some "chapter" visualization in
>   Coverswitch, or columns / grid in Present Windows
Easy to achieve as TabBox uses a QAbstractItemModel internally. Changing that 
to a TreeModel and sorting by Activities should rather trivial. Also TabBox 
could easily be extended to switch Activities.

More difficult is it in the effects: windows from other activities are 
unmapped, so we do not have the pixmap/texture for it (see empty spaces bug in 
Present Windows/Desktop Grid). We could use the multiple desktop hack, but 
that won't work if a system starts with multiple activities. For me it looks 
like effects and activities are not trivially possible.

Cheers
Martin


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: roadmap of the chime feature in the analog clock

[Steven Sroka]

On 1 February 2011 07:50, John Layt  wrote:
> On Saturday 15 January 2011 19:29:29 sunny sharma wrote:
>
>> To make things clear for me i would reguest you guys to tell me the further
>> steps that i should take.
>> So that i can clear up my mind and come up with a clear algorithm of what
>> should be done.
>
> [Catching up on my email now that I'm back from holiday]
>
> The problem here is the old one of balancing features for the power users
> against ease of use for the majority of users, it just means we have to make
> the code do more of the work instead of the user, or rather just be smarter
> about it.
>
> The most common features of chiming clocks are:
>  * Quarters, i.e. different chimes at 00, 15, 30 and 45
>  * Striking the hour, i.e. 12 strikes at midnight
>  * The hour chime plays before the hour, with the first hour strike playing
> exactly on the hour
>
> Combined with the "Speak Time" feature, we would obviously want to allow
> slightly more options, such as only chiming/speaking on the hour, turning off
> striking the hours (which can get very annoying and is meaningless for speak
> time), or chiming/speaking every x minutes.  I'm sure people can think of
> plenty more "nice-to-have-but-rarely-used" options that we don't want to
> expose most users to.

I don't know if this falls under the category of
"nice-to-have-but-rarely-used" but could there be an option available
that allows chimes to be disabled if the computer is actively being
used (eg. there are mouse clicks or keyboard button presses or a movie
is being played, etc).

I myself would like my computer to chime every hour as if I had my own
Big Ben in my living room. Big Ben being the large clock tower in
London, England :)

But, of course, having my computer chime in the middle of watching a
movie or something along the lines of that would sooo annoying.

>
> Expecting a user to configure a ui for all that is just not on.
>
> The key to keeping it simple is to NOT allow the user to configure the sounds
> and when they play in the ui as most users will never need to do this, and
> catering for all the options is just too complex.  Instead we would define a
> Chime Theme file format that we and power users can use to configure how a
> Chime Theme works and what sound files to use, and provide the user with a
> simple list of available themes to choose from.  We could even allow
> downloading new themes from GHNS, in which case we would ship KDE with just a
> very simple theme.
>
> Here's how a single ui section for "Audible Feedback" in the "General" tab
> would look like:
>
> A combo for "Feedback Type" with options for:
>  * None
>  * Speak Time
>  * Play Chimes
>
> A combo for "Frequency" that is activated only if "Feedback Type" is not
> "None", with options for:
>  * Chime Theme Defaults (only show if "Play Chimes" chosen)
>  * Hourly
>  * Quarters
>  * Every x Minutes (better wording needed)
>
> (Note that Hourly and Quarters are just synonyms for every 60 or 15 minutes.)
>
> Next to this combo is a minutes input spin box activated when "Every x
> Minutes" is chosen.  Alternatively we do "Frequency" as a radio button with
> the spinbox inline in the "Every x minutes" text.
>
> A combo for "Chime Theme" which is only activated if "Play Chimes" is
> selected, with a list of the currently available themes:
>  * Beep
>  * Time Pips
>  * Westminster
>  * Cuckoo
>  * ...
>
> Next to this could be a GHNS button to download more themes.
>
> Optionally under this could be a tick-box for "Strike Hours" which is only
> activated if "Play Chimes" is activated, to turn off striking hours which
> could get annoying.  Alternatively it could be integrated into the "Feedback
> Type" combo as separate options for "Play Chimes and Strikes" "Play Chimes
> Only" and "Play Strikes Only".
>
> I think 3 or 4 lines of simple config options is not too bad.  The "Feedback
> Type" and "Chime Theme" could even be merged for an even simpler interface.
>
> The Chime Theme would actually be a self-contained folder holding a config
> file and all required sound files, and would look something like this:
>
>  sounds/chimes/themename/
>    themename.desktop - Holds name of theme and default config options
>    default.ogg       - Default sound to play if no specific sound
>    strike.ogg
>    hour.ogg
>    quarterpast.ogg
>    half.ogg
>    quarterto.ogg
>
> In the .desktop file itself, the config options would allow you to point to
> other sound files in other locations and set default frequency, e.g.:
>
>    [Sounds]
>    hour=/media/data/audio/sounds/doh.wav
>
> There's lots of options that could be set here, but I won't detail them now.
>
> Some possible Chime Themes:
>
> Beep:         A simple beep with slightly different ones for hours, quarters,
>              and minutes. Ship with KDE, download the rest.
> Time Pips:    http://en.wikipedia.org/wiki/Greenwich_Time_Signal
> Westminster:  http://en.wikipedia.org/wiki/Westminster_Quarters
> Whittington:  

Re: the next step on the desktop: a widget at all activities

[Aaron J. Seigo]

On Tuesday, February 1, 2011, J Janz wrote:
> However, it'd be quite helpful to have Video, Audio and Image activities,
> where, taking the same amount of space at the desktop, I could have
> respective folderviews grouped with some more plasmoids to easily provide
> me more related content. For example, at Video I want a Web Slice with TV

this is what "clone activity" is so nice for. being able to save an activity 
as a template (should not be hard; i demonstrated the basics in javascript 
some months ago, it wouldn't be much hader in C++) would open new 
possibilities as well, as we already have template based creation.

> became too small for the needs and has to be resized. Desktop and Dowloads
> folderviews would be resized/repositioned once to all activities and
> activities' specific plasmoids, if grouped, would only take one
> resizing/repositioning to each group.

and if you have other widgets on the other containments, it'll be so very easy 
to end up with an utter mess as a result. which means people will then want to 
be able to "break the group" and resize just that one individually. and then 
we'd need UI to be able to manage which activities a widget is on.

ignoring that this completely fights the internal design and will cause pain 
for things such as "when you export an activity, should the groupings be 
maintained as well?", this seems like a relatively niche idea that would carry 
a ton of overhead.

i can imagine things like "containments in more than one activity" and then 
have a way to switch between containments on a single screen associated with 
an activity ... but again it ends up being more complexity, more UI, more 
management and more code to juggle it all.

KISS.

-- 
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: the next step on the desktop: a widget at all activities

[Marco Martin]

On Tuesday 01 February 2011, Aaron J. Seigo wrote:
> On Tuesday, February 1, 2011, Marco Martin wrote:
> > if on the other hand we would make possible like windows to send a widget
> > to a subset of activities, this would become quite more complexm and i'm
> > not sure is really something we want to go intom, but maybe with nice
> > enough use cases... ;)
> 
> honestly, i can only see tragedy coming of it.

yeah, could burst into flames in many interesting ways ;)

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

Re: the next step on the desktop: a widget at all activities

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Marco Martin wrote:
> if on the other hand we would make possible like windows to send a widget
> to a subset of activities, this would become quite more complexm and i'm
> not sure is really something we want to go intom, but maybe with nice
> enough use cases... ;)

honestly, i can only see tragedy coming of it.

-- 
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: the next step on the desktop

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Mario Fux wrote:
> Yes. Should be more about documents and not about applications. The user
> knows about documents and "files" but shouldn't need to know about
> applications. E.g. "click on a document or media file" and not "start
> application xyz".

for document centric work, yes. for things that revolve around contacts (e.g. 
IM), yes. but there are still many application centric tasks, like playing 
kpat, using marble or studying with one of the KDE Edu apps.

-- 
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: the next step on the desktop: Improving Activities UI

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Sebastian Kügler wrote:
> Activities are indeed one of the big things. I think we've got the basics
> right in 4.6, but it's not an obvious thing to integrate into your
> workflow, yet.

yes, seems like a good target for 4.7...

> - easily assigning a window to an Activity
>   The context menu is tricky to handle, requires a bunch of clicks and very
>   exact navigation. With a crappy touchpad, it's almost unusable, and not
>   obvious at all. Moreover, moving a window from one to another Activity
>   requires us to do it twice. Multiply that per WIndow, and you easily get
> an overhead that makes using Activities not worth it anymore

it gets complicated by being allowed to have a window in more than one 
activity. a nice "activity sorter" should be possible with a kwin effect that 
shows all the activities as target drop boxes with windows in them and an 'All 
activities' area at the top of the screen. then drag and drop could be used to 
sort windows. (goes nicely with your overview effect mentioned later).

for single windows, a button in the title bar could perhaps trigger that 
effect (and show the plain ol' menu in the non-composited case?) with just the 
one window letting you move it around easily.

where this gets trickier is when a window can be in more than one activity. if 
we had just "all activities" or "that one activity" then it becomes a lot more 
straightforward to manage.

what are our use cases for windows belonging simultaneously to multiple 
activities? are they worth enough to complicate the UI for?

if we do keep it, then one option might be to have a key combo to hold, or 
mouse button?, during drag to differentiate between "move that window from 
where it is to somewhere new" and "also put that window over in that other 
activity".

> - Having an overview mode per Activity
>   Touches the above, it's kind of hard to see what belongs to an Activity
> and to move things in between Activities. I regularly open a webbrowser to
> procrastinate, but hardly every remember changing Activity first. Then,
> while "consciously procrastinating", I've got to find my webbrowser back
> in one of the useful Activities

in addition to overview, we need to make it quicker to switch between 
activities; which is why i'd like a button on the panel for it.

> - More advanced Activity selector per Window. Maybe some kind of
> Activitybar with checkboxes integrated into the windeco, or as window
> overlay?

the part that i don't have any good answer for yet is how to trigger such a 
thing. if we wanted to "bet big" on it, we could add a new button to the 
window title bar so it's a single click; problem there being that title bars 
are often not that big and very abstract so any such button that was 
recognizable (e.g. the activities icon) would end up looking a bit alien.

just not sure yet :)

> - Overview mode per Activity, maybe some variation of Present Windows with
>   special layout (columns per Activity?)?

this reminds me of some of the early ideas worked out in Randa; i think it is 
very much worth trying out as a KWin effect and see how it goes.

-- 
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: the next step on the desktop: a widget at all activities

[Marco Martin]

On Tuesday 01 February 2011, J Janz wrote:
> became too small for the needs and has to be resized. Desktop and Dowloads
> folderviews would be resized/repositioned once to all activities and
> activities' specific plasmoids, if grouped, would only take one
> resizing/repositioning to each group.
> 
> That being, how does setting a widget for all activities sound for 4.7?
> 

I still didn't made my mind about if this would be a good thing to have or 
not.

i do see ways to do it, that aren't exactly clean, but perhaps not 100% 
impossible.
panel widgets are already this way...
sending a widget to all activities, could mean moving it to a containment 
overlayd tho the current activity containment, that is not actually associated 
to all activities.
if on the other hand we would make possible like windows to send a widget to a 
subset of activities, this would become quite more complexm and i'm not sure 
is really something we want to go intom, but maybe with nice enough use 
cases... ;)

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

Re: the next step on the desktop

[Marco Martin]

On Tuesday 01 February 2011, Sebastian Kügler wrote:

> > hm, yes, good points. perhaps we could do some sort of melding of what
> > the newspaper containment does? a search area at the top, with results
> > filling in  below it, and a scrollable grid for widgets below that?
> 
> Hm, maybe we would add (most of?) the flexibility we need by making SAL an
> Applet, instead of a Containment (or offer both versions).
well, it's already an applet ;)
now it's not selectable because using it as an applet is very, very rough

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

Re: the next step on the desktop: a widget at all activities

[J Janz]

Boy, what a huge thread!

I'm sorry I couldn't read it entirely yet (and even less find out about this
around the web) and I'm sorry if you guys might have talked about it before
but, as don't see it and you've been discussing activities, I want to offer
at least something to polish the edges. I might be foreseeing a gray area
between Activities and Virtual Desktops (but I'll save it for another mail
-- specially to try reading a bit more about both and see if I'm not missing
something) and, the idea I want to share here and actualy and currently
miss, having a widget at all activities. Here's my use case for the latter:

I download and produce videos, pictures, music and what not. Apps (usually
KDE's and GTK ones) often don't care where I want each content (mostly they
want to save stuff at my home folder, desktop folder or documents folder,
even though there are Downloads, Videos, Images and Music paths well defined
at System Settings). I know, it's a matter of fixing the apps but I don't
see it happening any soon (and I'm not able to do so) and, also, it turned
out to be better by giving me sort of a staging area for deciding which
content I'll keep. So, stuff I download always go to Downloads folder and
stuff I make always go to Desktop folder and both stay there 'till I see
they worth going to the right place. Then right now I have Downloads and
Desktop folderviews on top of Videos, Music and Images folderviews and
manually move files between them. These folderviews take a little more than
the horizontal half of my desktop.

However, it'd be quite helpful to have Video, Audio and Image activities,
where, taking the same amount of space at the desktop, I could have
respective folderviews grouped with some more plasmoids to easily provide me
more related content. For example, at Video I want a Web Slice with TV guide
showing currently running and next shows (from a satellite tv company's web
page) and at Audio I'd like to add Now Playing. The thing is I'd also need
Desktop and Download folderviews to each and, of course, the best would be
having them at the same place and size among all (so, taking no brain and
basicly muscle memory to move files from these folderviews to respective
ones at each Activity), specially if, say, Downloads folderview became too
small for the needs and has to be resized. Desktop and Dowloads folderviews
would be resized/repositioned once to all activities and activities'
specific plasmoids, if grouped, would only take one resizing/repositioning
to each group.

That being, how does setting a widget for all activities sound for 4.7?

And, sure, thank you, guys, for the great work 'till here and coming!

Cheers,
--
J (|´:¬{)»
-
"Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?"
O Senhor, Jesus Cristo - Jo.11:25-26
-
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Sebastian Kügler]

On Monday, January 31, 2011 21:22:51 Aaron J. Seigo wrote:
> > * it's not really done for containing applets, would almost mean
> >
> > dropping desktop widgets:
> >   - right now it contains widgets in a little panel like strip with
> >
> > horizontal form factor. now overly pretty.
> >
> >   - making it contain free layout applets like the desktop would look
> >
> > quite dirty since applets would cover the launcher icons randomly
> 
> hm, yes, good points. perhaps we could do some sort of melding of what the 
> newspaper containment does? a search area at the top, with results filling
> in  below it, and a scrollable grid for widgets below that?

Hm, maybe we would add (most of?) the flexibility we need by making SAL an 
Applet, instead of a Containment (or offer both versions).
-- 
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: Automatic activity switching and other stuff -- thoughts for 4.7

[John Layt]

On Sunday 19 December 2010 08:49:34 Ryan Rix wrote:
> I've been thinking a lot about how to give the Activity Manager a way to
> predict what a user would like to be doing at a certain time, based on
> external input, whether that's things like current GPS coordinates, what is
> scheduled in KOrganizer right now, etc. What follows is a braindump of crap
> I've been contemplating since before akademy, and it may well not make any
> sense.

[Finally catching up on my mail after holidays]

Nice to see some thinking going on around this.  I blogged about this sort of 
thing a while back as a generic concept of Events triggering Actions which you 
might be interested in reading (see 
http://www.layt.net/john/blog/odysseus/the_reactive_desktop and be sure to 
follow the link to Marco Polo) and with the new Activities stuff this is 
looking more achievable. I'm still looking into the geolocation side of things 
(hopefully have a state-of-the-onion email on that soon) but would be happy to 
kick ideas around sometime.

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

Re: roadmap of the chime feature in the analog clock

[John Layt]

On Saturday 15 January 2011 19:29:29 sunny sharma wrote:

> To make things clear for me i would reguest you guys to tell me the further
> steps that i should take.
> So that i can clear up my mind and come up with a clear algorithm of what
> should be done.

[Catching up on my email now that I'm back from holiday]

The problem here is the old one of balancing features for the power users 
against ease of use for the majority of users, it just means we have to make 
the code do more of the work instead of the user, or rather just be smarter 
about it.

The most common features of chiming clocks are:
 * Quarters, i.e. different chimes at 00, 15, 30 and 45
 * Striking the hour, i.e. 12 strikes at midnight
 * The hour chime plays before the hour, with the first hour strike playing 
exactly on the hour

Combined with the "Speak Time" feature, we would obviously want to allow 
slightly more options, such as only chiming/speaking on the hour, turning off 
striking the hours (which can get very annoying and is meaningless for speak 
time), or chiming/speaking every x minutes.  I'm sure people can think of 
plenty more "nice-to-have-but-rarely-used" options that we don't want to 
expose most users to.

Expecting a user to configure a ui for all that is just not on.

The key to keeping it simple is to NOT allow the user to configure the sounds 
and when they play in the ui as most users will never need to do this, and 
catering for all the options is just too complex.  Instead we would define a 
Chime Theme file format that we and power users can use to configure how a 
Chime Theme works and what sound files to use, and provide the user with a 
simple list of available themes to choose from.  We could even allow 
downloading new themes from GHNS, in which case we would ship KDE with just a 
very simple theme.

Here's how a single ui section for "Audible Feedback" in the "General" tab 
would look like:

A combo for "Feedback Type" with options for:
 * None
 * Speak Time
 * Play Chimes

A combo for "Frequency" that is activated only if "Feedback Type" is not 
"None", with options for:
 * Chime Theme Defaults (only show if "Play Chimes" chosen)
 * Hourly
 * Quarters
 * Every x Minutes (better wording needed)

(Note that Hourly and Quarters are just synonyms for every 60 or 15 minutes.)

Next to this combo is a minutes input spin box activated when "Every x 
Minutes" is chosen.  Alternatively we do "Frequency" as a radio button with 
the spinbox inline in the "Every x minutes" text.

A combo for "Chime Theme" which is only activated if "Play Chimes" is 
selected, with a list of the currently available themes:
 * Beep
 * Time Pips
 * Westminster
 * Cuckoo
 * ...

Next to this could be a GHNS button to download more themes.

Optionally under this could be a tick-box for "Strike Hours" which is only 
activated if "Play Chimes" is activated, to turn off striking hours which 
could get annoying.  Alternatively it could be integrated into the "Feedback 
Type" combo as separate options for "Play Chimes and Strikes" "Play Chimes 
Only" and "Play Strikes Only".

I think 3 or 4 lines of simple config options is not too bad.  The "Feedback 
Type" and "Chime Theme" could even be merged for an even simpler interface.

The Chime Theme would actually be a self-contained folder holding a config 
file and all required sound files, and would look something like this:

  sounds/chimes/themename/
themename.desktop - Holds name of theme and default config options
default.ogg   - Default sound to play if no specific sound
strike.ogg
hour.ogg
quarterpast.ogg
half.ogg
quarterto.ogg

In the .desktop file itself, the config options would allow you to point to 
other sound files in other locations and set default frequency, e.g.:

[Sounds]
hour=/media/data/audio/sounds/doh.wav

There's lots of options that could be set here, but I won't detail them now.

Some possible Chime Themes:

Beep: A simple beep with slightly different ones for hours, quarters,
  and minutes. Ship with KDE, download the rest.
Time Pips:http://en.wikipedia.org/wiki/Greenwich_Time_Signal
Westminster:  http://en.wikipedia.org/wiki/Westminster_Quarters
Whittington:  http://en.wikipedia.org/wiki/Whittington_chimes
Ships Bells:  http://en.wikipedia.org/wiki/Ship%27s_bells

At first glance it may seem a fairly complex solution, but I think the 
implementation will actually be fairly simple and not add much overhead, the 
hardest part is designing the config file to be flexible enough.

John.

P.S. This is what you get from staring at the ceiling at 4am in the morning 
thanks to jet-lag :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Sebastian Kügler]

On Monday, January 31, 2011 18:17:58 Martin Gräßlin wrote:
> Ah and they deprecated the systray without having a replacement, but well
> not  our problem ;-)

Au contraire. ;) The replacement is "unversioned javascript snippets" which 
you dump into some system directory, which then hook into GNOME shell and a 
whitelist of applications that may abuse the system tray area.
-- 
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: the next step on the desktop: Improving Activities UI

[Sebastian Kügler]

Activities are indeed one of the big things. I think we've got the basics 
right in 4.6, but it's not an obvious thing to integrate into your workflow, 
yet.

On Monday, January 31, 2011 20:55:56 Aaron J. Seigo wrote:
>   On Monday, January 31, 2011, Ivan Cukic wrote:
> > > * have all activities avaiable in kactivitmanagerd, even if they are
> > > "stopped" in plasma-desktop
> >
> > ? Activities that are stopped are still in kamd.
> 
> hm.. but they don't show up in window titlebar context menus when they are 
> stopped; so a "bug" in kwin, then? it should be possible imho to send
> windows  to any defined activity. we could put the stopped activities at
> the bottom of the menu after a separator to help keep the running ones
> more prominent and easier to find?

After using it for a bit, I think the activities context menu is quite 
useless, because hard to handle. While getting used to an activity-based 
workflow, I've tried to identify some things that would make them more useful 
and more obvious how it works:

- easily assigning a window to an Activity
  The context menu is tricky to handle, requires a bunch of clicks and very 
  exact navigation. With a crappy touchpad, it's almost unusable, and not 
  obvious at all. Moreover, moving a window from one to another Activity 
  requires us to do it twice. Multiply that per WIndow, and you easily get an 
  overhead that makes using Activities not worth it anymore

- Having an overview mode per Activity
  Touches the above, it's kind of hard to see what belongs to an Activity and 
  to move things in between Activities. I regularly open a webbrowser to 
  procrastinate, but hardly every remember changing Activity first. Then, 
  while "consciously procrastinating", I've got to find my webbrowser back in 
  one of the useful Activities


Possible solutions:

- More advanced Activity selector per Window. Maybe some kind of Activitybar 
  with checkboxes integrated into the windeco, or as window overlay?

- Overview mode per Activity, maybe some variation of Present Windows with 
  special layout (columns per Activity?)?

- Making KWin's taskswitcher more Activity-aware, for example by grouping 
  windows in the Boxswitch, by having some "chapter" visualization in 
  Coverswitch, or columns / grid in Present Windows

Not sure how complete it would feel, but I think the above could fill in the 
missing link and make it more obvious how Activities work, by giving more 
visual hints.

That would IMO be one piece of the puzzle. It could easily go on some kind of 
start screen, so you log into KDE and get some big buttons "Procrastinate", 
"Work-Work", "KDE", much like the application shortcuts on the "classic 
desktop of the 90s", but on a much higher level.
-- 
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: the next step on the desktop

[Marco Martin]

On Tuesday 01 February 2011, Dario Freddi wrote:
> Aaron, thanks for putting this to attention. I want to add some other
> points which are relevant to me and I think fit well into this context.
> Sorry for not replying to other points, but I see a lot of enthusiasm,
> which is awesome, but also translates to: too much text :D
> 
> However, preamble: these days I'm using Mac OS for some tasks, and while I
> am proud about missing a LOT of stuff from KDE, and think KDE is overall
> better, I have found myself missing some small things in Mac OS.
> 
> The very first one is: multitouch gestures on the touchpad. In Mac OS,
> using a four-finger swipe triggers present window or show desktop,
> depending on the direction of the swipe. This is a TOTAL game changer in
> usability imo, as you are able to access windows or desktop through a
> single gesture. I think this would be a great target and rather simple to
> implement, given that the underlying architecture is ready - maybe
> somebody else can comment on that.

It (as usual) all depends fro the hardware support i fear :/

I know  QTouchEvents and the higher level gestures in Qt are supported on osx 
wit their touchpads.
no idea under linux tough (i would guess no, since the multitouch framework 
directly reads from the event device of exactly the touchscreen panel it's in 
the lenovos, that also, support only two input points)
It will migrate to XI2 tough, so should become less hacky.

also, the mac touchpads i think are quite different from the usual synaptic in 
the other laptops, there is some gesture support i think, but dunno how much 
access there is to this stuff.

Aanyways, i think everybody that has any kind of device where qt supports 
qtouchevents should play with them as much as they can, so when the underlying 
stack becomes less a tragedy, those things should start to work for everybody. 

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

Re: the next step on the desktop

[Sebastian Kügler]

On Tuesday, February 01, 2011 01:09:54 Markus Slopianka wrote:
> Dude, calm down a little. I was blaming no one of anything.

Actually, Aaron expressed my thoughts about your comments exactly. It's not 
about calming down, but about having a useful discussion among Plasma 
developers. People don't just take part to advance their own agenda, we're 
having this discussion to determine direction.
-- 
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: the next step on the desktop

[Dario Freddi]

Aaron, thanks for putting this to attention. I want to add some other points 
which are relevant to me and I think fit well into this context. Sorry for not 
replying to other points, but I see a lot of enthusiasm, which is awesome, but 
also translates to: too much text :D

However, preamble: these days I'm using Mac OS for some tasks, and while I am 
proud about missing a LOT of stuff from KDE, and think KDE is overall better, 
I have found myself missing some small things in Mac OS.

The very first one is: multitouch gestures on the touchpad. In Mac OS, using a 
four-finger swipe triggers present window or show desktop, depending on the 
direction of the swipe. This is a TOTAL game changer in usability imo, as you 
are able to access windows or desktop through a single gesture. I think this 
would be a great target and rather simple to implement, given that the 
underlying architecture is ready - maybe somebody else can comment on that.

Another one, is how their equivalent of System Settings is handled. They 
solved the problem of default sizes by making it automatically resize when a 
module loads. Sure, it requires all the modules to adhere to some guidelines 
and whatnots, but it could be a good way to spot systemsettings' current 
weakness, or still a good point to start thinking about how to solve the apps' 
default size disaster.

More than that, I also had some other ideas, more than agreeing with Aaron on 
his points, but I'll save those for another mail - gotta get back to study :D

On Monday 31 January 2011 02:22:41 Aaron J. Seigo wrote:
> hi...
> 
> back when we started the path towards plasma i said that we needed to
> slowly evolve the desktop beyond the desktop folder with icons littered on
> the desktop.
> 
> now we have activities, kick-ass containments like search and launch and
> grouping desktop.
> 
> it is time to go to that next step and move people away from the old ways.
> 
> i was at a friend's house last night where a bunch of people gathered to
> hang out, chat, play games, etc. there was a desktop system there running
> plasma desktop with the search and launch containment and a gorgeous
> translucent panel couresty of kwin.
> 
> i saw it and hardly recognized it: it looked new, amazing, the next thing.
> it looked amazing.
> 
> so, here's my suggestion for 4.7:
> 
> let's try something big and new. let's make that Big Move and step away
> from ~/Desktop.
> 
> my proposal is this:
> 
> * by default, Search and Launch on the desktop
> * an icon in this S&L that takes you to your desktop folder .. in a file
> manager.
> * a new panel layout (TBD: let's work on this together!)
> * improve the tasks widget to have some of the nice features of widgets
> like "smooth tasks" with the mouse over highlights
> * an "activities" widget (i'll hapilly write it) that sits next to the app
> launcher and when clicked brings up the actvities manager
> * an activities switcher as a kwin effect (!)
> * have all activities avaiable in kactivitmanagerd, even if they are
> "stopped" in plasma-desktop
> 
> thoughts?

-- 
---

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: the next step on the desktop

[Mario Fux]

Am Montag 31 Januar 2011, 14.42:01 schrieb Marco Martin:
> On Mon, Jan 31, 2011 at 2:22 AM, Aaron J. Seigo  wrote:

Morning

Finally I have read all the mails of this thread and hope to add some valuable 
information and no redundant one.

> > back when we started the path towards plasma i said that we needed to
> > slowly evolve the desktop beyond the desktop folder with icons littered
> > on the desktop.
> > 
> > now we have activities, kick-ass containments like search and launch and
> > grouping desktop.
> 
> the biggest thing that have to be worked on, is making applications
> activity aware, it's the only way to convince people that activities
> are -not- virtual desktops ;)

The Randa meeting and in particular the Nepomuk would be a great opportunity 
for this. We (Nepomuk) would like to integrate Nepomuk (and thus activity) 
stuff and as many apps as possible.

> > it is time to go to that next step and move people away from the old
> > ways.
> 
> yep, I would still like to push desktop beyond the desktop, resistence
> against is so amazing that i find it harder and harder.
> we need a concentrated effort between all areas for this i think, not
> just plasma ;)
> 
> > i was at a friend's house last night where a bunch of people gathered to
> > hang out, chat, play games, etc. there was a desktop system there
> > running plasma desktop with the search and launch containment and a
> > gorgeous translucent panel couresty of kwin.
> 
> i do think s&l looks great in the dashboard, however i have some
> issues of it being in the desktop, will explain later ;)
> 
> > let's try something big and new. let's make that Big Move and step away
> > from ~/Desktop.
> 
> to me the biggest dumb thing is ~/Desktop itself, not much having
> icons on desktop (in the form of folderview applets)
> having n folderviews topic-specific goes very well with the concept of
> activities.
> the biggest hurdle is always the fact of having them in a
> background-ish desktop.
> 
> > my proposal is this:
> > 
> > * by default, Search and Launch on the desktop
> 
> There are several issues with s&l:
> * it's not really done for big screens, there is a sad line of icons
> sitting in the middle of the desktop
> * it's not really done for containing applets, would almost mean
> dropping desktop widgets:
>   - right now it contains widgets in a little panel like strip with
> horizontal form factor. now overly pretty.
>   - making it contain free layout applets like the desktop would look
> quite dirty since applets would cover the launcher icons randomly
> * being always mostly covered by windows limits the usefulness, as i
> said great in dashboard (this is quite true for widgets as well, but
> being smaller the problem is less strong)
> * it empasizes the concept of starting apps, (or "start menu" if you
> want) a lot, that's really something i would like to get away with

Yes. Should be more about documents and not about applications. The user knows 
about documents and "files" but shouldn't need to know about applications. 
E.g. "click on a document or media file" and not "start application xyz".

> what about having it (or something similar) that appears as a big
> sidebar of the screen when clicking on the K icon?
> 
> > * an icon in this S&L that takes you to your desktop folder .. in a file
> > manager.
> 
> could be, i would still rather find a way to encoourage use of
> folderview as activity relevant file containers tough
> 
> > * a new panel layout (TBD: let's work on this together!)
> 
> a long due thing is moving app systray items in the taskbar and even
> hiding all xembed icons by default (but, a voluntary is needed to have
> this done)
> 
> > * improve the tasks widget to have some of the nice features of widgets
> > like "smooth tasks" with the mouse over highlights
> 
> yeah, either the tooltip has to be improved a lot or the tasks widget
> using its own, like the widgets explorer
> 
> > * an "activities" widget (i'll hapilly write it) that sits next to the
> > app launcher and when clicked brings up the actvities manager
> 
> there is one on kde-look. however i remeber that you had a valid
> argument against it: it would slowly become basically a replica of the
> activity manager with most-but-not-all of its features.
> 
> > * an activities switcher as a kwin effect (!)
> 
> there is always the problem it would lie a bit if applications become
> aware of activities
> 
> > * have all activities avaiable in kactivitmanagerd, even if they are
> > "stopped" in plasma-desktop
> 
> +1
> 
> > toughts?
> 
> I think what this reflect, but still not really addresses is the limit
> of usefulness of the desktop window as is managed nowdays.
> 
> both widgets or the s&l have a quite limited usage if they are in
> background, so wanting to change what's inside it seems more a way to
> go around it (that's one of the reasons in netbook and mobile the
> desktop is not a desktop window, but it wouldn't work in
> plasma-desktop)...
> 

Re: the next step on the desktop

[Mario Fux]

Am Montag 31 Januar 2011, 21.29:01 schrieb Aaron J. Seigo:
> On Monday, January 31, 2011, Ivan Čukić wrote:

Morning

> > > hm.. but they don't show up in window titlebar context menus when they
> > > are stopped; so a "bug" in kwin, then? it should be possible imho to
> > > send windows to any defined activity. we could put the stopped
> > > activities at the bottom of
> > 
> > What would that do?
> > 
> > 1. Start the activity in question
> 
> that would be unexpected imho.
> 
> > 2. Stop the application and remember it should be in that activity
> > 2. Just assign the window to the activity (apart from the current one)
> > and do nothing else
> 
> if it is only associated with stopped activities, then it should probably
> "join them". if it is also associated with the current activity, then it
> should just be assigned. still thinking about it though :)
> 
> what would be really nice is if an iconic representation of the activity it
> was being associated with "popped up" somewhere on screen to reinforce the
> idea that the window had been added to it. if the app was stopped, the
> window would "minimize to it" like we do with the minimize action to the
> tasks widget now. if it was just associated with the activity, then
> perhaps the window title could "duplicate" and then go "into" the activity
> representation.

Oh. Visual effect that explain the processes going on. Great. I like it.
(Not that other visual effects don't do this).

> > > the menu after a separator to help keep the running ones more prominent
> > > and easier to find?
> > 
> > Yes... the sorting should be added everywhere.
> 
> +1

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

Re: the next step on the desktop

[Jeffery MacEachern]

>> i'm trying to imagine a clever way to make it easy to go from a folder
>> returned as a search result to a folderview on the desktop. it could be
>> offered as an action on the QueryMatch, for instance, and make it easy to
>> "pin" that folder to your current activity layout instead of going through
>> the widget explorer?
>
> drag and drop is good, then a runner action as well.
> it would be nice some action/gesture whatever to transform dolphin windows
> into folderviews and back, something that looks organic... hmmm.

That's an intriguing idea. If we were to do that, what about other
application/widget pairs? The Plasmoid handle (is that the name for
it?) already has support for that sort of thing functionally, but
visuals and further conceptual binding could be *really* slick.

> Cheers,
> Marco Martin

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

Re: the next step on the desktop

[Jeffery MacEachern]

On Mon, Jan 31, 2011 at 12:29, Aaron J. Seigo  wrote:
> On Monday, January 31, 2011, Ivan Čukić wrote:
>> > hm.. but they don't show up in window titlebar context menus when they
>> > are stopped; so a "bug" in kwin, then? it should be possible imho to
>> > send windows to any defined activity. we could put the stopped
>> > activities at the bottom of
>>
>> What would that do?
>>
>> 1. Start the activity in question
>
> that would be unexpected imho.
+1
>> 2. Stop the application and remember it should be in that activity
>> 2. Just assign the window to the activity (apart from the current one)
>> and do nothing else
>
> if it is only associated with stopped activities, then it should probably
> "join them". if it is also associated with the current activity, then it
> should just be assigned. still thinking about it though :)

The feasibility of this would depend on how the Activity assignment is
(re?)done, IMO. For example, in the KWin Activities menu, you have to
perform each (de)assignment individually, which - with this proposal -
could result in accidentally "disappearing" an application that you
were going to pin to a running activity as well.

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

Re: the next step on the desktop

[Jeffery MacEachern]

On Mon, Jan 31, 2011 at 12:22, Aaron J. Seigo  wrote:
> On Monday, January 31, 2011, Marco Martin wrote:
>> On Mon, Jan 31, 2011 at 2:22 AM, Aaron J. Seigo  wrote:
>> > let's try something big and new. let's make that Big Move and step away
>> > from ~/Desktop.
>>
>> to me the biggest dumb thing is ~/Desktop itself, not much having
>> icons on desktop (in the form of folderview applets)
>> having n folderviews topic-specific goes very well with the concept of
>> activities.
>> the biggest hurdle is always the fact of having them in a
>> background-ish desktop.
>
Heh. I find the biggest problem with the traditional Desktop Metaphor
is that it holds *too* well - i.e. my ~/Desktop used to look like my
physical desktop. :)

> agreed; i do also like the idea of having SAL features right there, though.
> it's such a compelling use of widgets-on-the-desktop and looks really pretty
> as a bonus.
>
>> > my proposal is this:
>> >
>> > * by default, Search and Launch on the desktop
>>
>> There are several issues with s&l:
>> * it's not really done for big screens,
>
> true
>
>> there is a sad line of icons sitting in the middle of the desktop
>
> it actually looks pretty good on large screens. i was surprised by how good,
> in fact.

Come to think of it, I agree with this. I think the screen in question
was a 21", and it looked great! That's not to say it wasn't "wasting"
space, but it was still quite impressive.

>> * it's not really done for containing applets, would almost mean
>> dropping desktop widgets:
>>   - right now it contains widgets in a little panel like strip with
>> horizontal form factor. now overly pretty.
>>   - making it contain free layout applets like the desktop would look
>> quite dirty since applets would cover the launcher icons randomly
>
> hm, yes, good points. perhaps we could do some sort of melding of what the
> newspaper containment does? a search area at the top, with results filling in
> below it, and a scrollable grid for widgets below that?

Hmm... I like this. One could even imagine a melding of widgets and
runners into a sort of transient widget-space: if I can search the
Web, look up definitions, and do calculus in a Runner, why couldn't we
have other content or interactive widgets that can be called up on
demand. This is a bit out there, but it could be an interesting
concepts.

>> * being always mostly covered by windows limits the usefulness, as i
>> said great in dashboard (this is quite true for widgets as well, but
>> being smaller the problem is less strong)
>
> there are a few things we could do to "fix" this... e.g. when you click in the
> search edit we could trigger it forward as a dashboard, and we could advertise
> the keyboar shortcut for pulling it forward in the click message text of the
> search edit?
>
>> * it empasizes the concept of starting apps, (or "start menu" if you
>> want) a lot, that's really something i would like to get away with
>

Why do you want to get away from that? (I'm not arguing, just curious)

> it has / could have more uses than just that, though. a google-on-your-desktop
> ..
>
> if we use our imaginations a bit, i bet we could come up with all sorts of
> useful things. e.g. with the widgets runner, it could be used to add widgets
> to the desktop in response to queries: "cpu temp" and there i have a
> cpu temp monitor on my desktop. there must be dozens of such ideas?

See above ^ :)

>> what about having it (or something similar) that appears as a big
>> sidebar of the screen when clicking on the K icon?
>
> well, that'd be krunner or lancelot or raptor :) different concepts imo.
>
>> > * an icon in this S&L that takes you to your desktop folder .. in a file
>> > manager.
>>
>> could be, i would still rather find a way to encoourage use of
>> folderview as activity relevant file containers tough

+1
Chani and I were talking about Activity support for KFilePlaces*,
which might have some bearing here as well...

> i'm trying to imagine a clever way to make it easy to go from a folder
> returned as a search result to a folderview on the desktop. it could be
> offered as an action on the QueryMatch, for instance, and make it easy to
> "pin" that folder to your current activity layout instead of going through the
> widget explorer?
>
>> > * a new panel layout (TBD: let's work on this together!)
>>
>> > * an "activities" widget (i'll hapilly write it) that sits next to the
>> > app launcher and when clicked brings up the actvities manager
>>
>> there is one on kde-look. however i remeber that you had a valid
>> argument against it: it would slowly become basically a replica of the
>> activity manager with most-but-not-all of its features.
>
> indeed; i was simply envisioning a button that would launch the full activity
> manager UI. right now it is very hidden.

+1

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