In the elevator pitch I miss some mention to the existing support behind the
Plasma platform.
Something along the lines of "In addition to the community work, Plasma
development is supported by $BIG_COMPANY_NAME", where $BIG_COMPANY_NAME
currently could use the names of Nokia, Intel, AMD... for Me
On 7 September 2010 14:33, Asraniel wrote:
> Appart from the wrongly choosen icon (which looks like a refresh button), i
> really can't see any problem with that feature.
> Don't let us go the gnome way and delete every feature that not at least
> 100%
> of the people use.
>
I don't think we're t
On 7 September 2010 13:13, Anne-Marie Mahfouf wrote:
> Most Picture Frame users have several such applets on their desktop and
> rotate
> them to get a visually improved desktop. The Picture Frame applet is
> probably
> the strongest use case in rotating widgets.
> I don't imagine using it without
On 18 August 2010 08:42, Chani wrote:
>
> Another tricky issue: how to represent the containments? If someone can get
> thumbnails of containments working properly I will give them lots of beer
> and
> hugs. :) Im the meantime... well, a grid of identical icons isn't very
> useful.
> there probabl
On 18 August 2010 08:42, Chani wrote:
> so... we had planned to have a little tool for managing the containments of
> multiple screens, in 4.5 - but there wasn't time. multiscreen has
> improvements, but also regressions - well, *a* regression - you can't
> access
> the containment of a screen th
On 17 August 2010 13:21, Marco Martin wrote:
> On Monday 16 August 2010, Stefan Majewsky wrote:
> > The reason why I'm writing this is because I started work on libkgame, a
> > collection of libraries which shall, at some point, supersede libkdegames
> > which is currently used by most games in th
ely more information: just icons when
the notification is small, more text as the panel grows.
Maybe you could use this kind of growing animation for bubbles, and try it
on some test users? I for one would prefer this style to the popups in the
N800/N900. I hate having one of those inter
Shouldn't that question be cross-posted to kde-usabil...@kde.org to have
more eyeballs? :-)
On 14 March 2010 23:50, Eduardo Robles Elvira wrote:
> In Artesanos we are working in the new KDE Bluetooth stack
>
> * Job Finished notification
>
> When a Job takes less than X seconds (currently, 1.5s)
r if both lists are merged or
if we have a "history only" list (when the text box is empty) and a "results
only" one (when typing).
> On March 9, 2010, Diego Moya wrote:
> > reimplementing exactly the same functionality in the main list, showing
> > previous queries
On 8 March 2010 23:39, Jacopo De Simoi wrote:
> This also definitely implies that it can be used as a search facility, it's
> not its main purpose but it does not necessarily conflict with the primary
> goal; in fact I find it a very useful tool.
>
I agree with that. It's not the search function
On 8 March 2010 01:42, Aaron J. Seigo wrote:
> this reminds me about jokes about the difference between theory and
> practice.
>
> if we remove the history then we'll get to deal with tons of bug reports
> about
> how you can't do "alt+f2, up arrow, enter" which is a very, very common use
> patte
On 28 February 2010 09:34, Aaron J. Seigo wrote:
> On February 27, 2010, Miha Čančula wrote:
> > I suggest that the history should be added as just another runner. It
> would
> > show the last N used things when started, and then display a filtered
> list
> > when you write something.
>
> which d
I personally set up Win+Space as the shorcut for the application launcher in
all the windowing environments I use. It has nearly the same convenience as
Alt+Space, and I've found that the Super-Meta-Win key is less overloaded
with key combos than Alt - so I can use it without running into any
confl
On 5 March 2010 12:12, Diego Moya wrote:
> I liked the idea someone proposed to create those buttons as plasmoids so
> that each user can decide where to place them (either inside the panel or on
> the desktop).
>
Oh - I forgot: another really good option is having the "hide&quo
Hi,
I'd like to step in to defend the interests of us KDE users who won't use
this feature. I want to make sure that it can be configured to not interfere
with my current workflow. My rational is that I've always found this KDE 3
panel feature a little bit annoying, and now the use case it provide
On 5 February 2010 18:44, Aaron J. Seigo wrote:
> Context is specific to the person in that it is the person's current internal
> state which defines which Context (if any) is applicable. it has nothing to do
> with the computer. in fact, Context is a way to make the computer reflect the
> person.
Short reply:
Move activities to the third dimension - they should be a
generalization of the plasma dashboard to N layers. Open windows
should adapt to the current selected layer (dashboard = all windows
autohide; other layers = show new background + show attached plasmoids
+ change Nepomuk-enable
Also, maybe the progress bar for running jobs could be placed *below*
the popups and NotificationScroller, instead of above. This way they
wouldn't jump up and down like that.
(I know, I know it was my idea putting them on top)...
On 1 February 2010 14:59, Diego Moya wrote:
> On 1
On 1 February 2010 14:41, Marco Martin wrote:
> for all who can't try trunk, a screencast of the current status is there:
> http://www.notmart.org/index.php/Software/The_future_of_notifications
Great work!
Is there a way to show the beginning of the message body for the
popups that are partially
2010/1/27 Marco Martin wrote:
> On Wednesday 27 January 2010, Diego Moya wrote:
> since given how i want to implement it one behaviour or the other would mean
> basically an one liner difference, we will be able to test both for a wile and
> see what seems better
Seems reasonabl
2010/1/27 Marco Martin wrote:
> the policy should be this:
> - if a new one arrives check if there is already a notification of the same
> app if it is remove that one
What if I didn't have time to read that one, because it got instantly
covered by a newer one? Then I'm forced to open (i) to revie
2010/1/27 Marco Martin wrote:
> the thing i did start to implement was funningly enough almost the same, only
Proof that local optima do exist for good designs, given the same
constraints! :-)
> thing, i still think the new ones should be piled in front of old ones, not
> behind
In what order d
. This doesn't take much space, and
still shows how many simultaneous alerts arrive.
2010/1/27 Aaron J. Seigo wrote:
> On January 26, 2010, Diego Moya wrote:
>> 2010/1/26 Aaron J. Seigo wrote:
> what i said is that showing all the previous notifications and jobs when a new
> n
2010/1/26 Aaron J. Seigo wrote:
> On January 26, 2010, Diego Moya wrote:
> for when the user specifically calls up the notifications (e.g. by expanding
> the popup or by clicking on the (i) icon), this will be great.
>
> for notifications that are auto-popped, it suffers from the i
Arriving late to the discussion, so just my 2 cents:
2010/1/26 Aaron J. Seigo :
> On January 26, 2010, Ivan Čukić wrote:
>> On Tuesday, 26. January 2010. 11.57.36 Riccardo Iaconelli wrote:
>> > On Monday 25 January 2010 13:20:56 Marco Martin wrote:
>> > > opinions? comments?
>> > > would like to h
2009/7/16 Martin Gräßlin :
> My idea is that with alt+tab it should work as ever known. But that it is not
> required to keep alt pressed (keeping it pressed shouldn't harm).
There's a way to achieve that goal without breaking the normal alt+tab
quasimode behavior.
Hold alt + tab as many times as
26 matches
Mail list logo
