Re: [Kde-games-devel] Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

2010-08-23 Thread Marco Martin 
On Sunday 22 August 2010, Stefan Majewsky wrote:

> Interestingly, I have just now written kdegames' own SVG rendering,
> painting and caching system, with all bells and whistles. (Ask api.kde.org
> for KGameRenderer.) The use case is different:
> * Plasma uses a theme composed of multiple SVG files, AFAIK to be able to
> fallback to the default theme when some of these SVG aren't available. OTOH
> our games use a single SVG theme which contains all visual components.
> * Plasma::Svg seems to be the lowest granularity of theme components.
> KGameRenderer has the KGameRendererClient which is attached to a single SVG
> element, and receives a new pixmap automatically, should the need arise.
> * While Plasma renders (AFAIK) nearly its complete UI from these themes,

so, a brief explanation is due:
Plasma draws its ui elements with a class called FrameSvg, that is a Svg 
subclass and composes the 9 elements needed to render something like a rounded 
button-ish look.
Svg is a class that opens an svg file and can draw it either complete or a 
single element of it, so having the whole graphics needed for a game in a 
single file is perfectly possible.

> games consist of a relatively small number of sprites. Progress bars etc.
> are (if at all) simple QWidgets. Of course, if we want to move everything
> into the themed game view, we will have to theme these elements, but I
> think that QML is a much more likely candidate there.

you will need some wrapper class to use svg from qml then bind for it, because 
there is nothing for svg

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

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Marco Martin 

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


this very patch appeared here for several times already.
and as usual, the question is: what real value gives over auto hiding the text 
when there is not enough space?

- Marco


On 2010-08-22 13:52:33, Björn Ruberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5078/
> ---
> 
> (Updated 2010-08-22 13:52:33)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds the option to put the taskbar in an icon-only mode - similar 
> as in Windows 7 . This is an much requested feature in bugzilla.
> It is fairly simple and just using features already existing in the code, 
> adding an m_showIconOnly member to the layout and the abstractitem plus the 
> adaption of the config ui.
> 
> 
> This addresses bug 159480.
> https://bugs.kde.org/show_bug.cgi?id=159480
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasksConfig.ui 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.cpp
>  1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.h 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 
> 1166313 
> 
> Diff: http://reviewboard.kde.org/r/5078/diff
> 
> 
> Testing
> ---
> 
> Moved panel around and made sure it works. Looks actually pretty good this 
> icon-only mode!
> 
> 
> Thanks,
> 
> Björn
> 
>

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

Re: Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

2010-08-23 Thread Marco Martin 
On Sunday 22 August 2010, Stefan Majewsky wrote:
> On Tuesday 17 August 2010 13:21:15 Marco Martin wrote:
> > hmm, this looks a bit like qml to me.
> > and yes i'm aware and agree on the concerns over its architecture, but
> > perhaps it should not be discarded before evaluating if it could have
> > some applications there
> 
> I am in the process of evaluating QML. I have only played with it a bit,
> yet I am sure that we could put it to good use.
> 
> Could you please expand on "concerns over its architecture"?

to me is mainly the implementation of a new base class, called 
QDeclarativeItem that is almost-but-not-quite QGraphicsWidget.
(and also the layout system is different, while is great is some cases, it is 
less in others) to me makes it quite challenging for doing rich applications 
ui.

anyways probably this affects games in way less extents, so it could be good 
enough (or you may find completely different issues that are strictly game 
related, i don't know :p)

> > paint rutines: we have a quite efficient svg loading and painting
> > mechanism with on disk cache of the rasterized stuff that seems to scale
> > pretty well on not-so-capable devies (when there aren't cache misses it
> > is possible to display svgs without instantiating any svg parser)
> 
> As I mentioned in my reply to Aaron, incidentally I implemented a similar
> solution for kdegames just at the beginning of the 4.6 cycle.

yes, looks quite similar indeed, looks like we sould had this thread way 
before eheh :)

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

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Björn Ruberg 
An Montag, 23. August 2010 11:00:46 schrieben Sie:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5078/#review7162
> ---
> 
> 
> this very patch appeared here for several times already.
> and as usual, the question is: what real value gives over auto hiding the
> text when there is not enough space?

It makes grouping - what increases the amount of clicks you need to get to 
your application by one - unnecessary. You can usually see what applications 
are running because you have to look at some icons only instead of having to 
look at the whole panel width. The later often needs eye movements (depends on 
your screen). It's much more appealing to have just an icon instead of a task-
item with a much shortened window title in it.

It it is on place six of the most wanted plasma features. 

> On 2010-08-22 13:52:33, Björn Ruberg wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/5078/
> > ---
> > 
> > (Updated 2010-08-22 13:52:33)
> > 
> > 
> > Review request for Plasma.
> > 
> > 
> > Summary
> > ---
> > 
> > This patch adds the option to put the taskbar in an icon-only mode -
> > similar as in Windows 7 . This is an much requested feature in bugzilla.
> > It is fairly simple and just using features already existing in the
> > code, adding an m_showIconOnly member to the layout and the abstractitem
> > plus the adaption of the config ui.
> > 
> > 
> > This addresses bug 159480.
> > 
> > https://bugs.kde.org/show_bug.cgi?id=159480
> > 
> > Diffs
> > -
> > 
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasksConfig.u
> >   i 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp
> >   1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayo
> >   ut.h 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayo
> >   ut.cpp 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttask
> >   item.h 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttask
> >   item.cpp 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupite
> >   m.h 1166313
> >   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupite
> >   m.cpp 1166313
> > 
> > Diff: http://reviewboard.kde.org/r/5078/diff
> > 
> > 
> > Testing
> > ---
> > 
> > Moved panel around and made sure it works. Looks actually pretty good
> > this icon-only mode!
> > 
> > 
> > Thanks,
> > 
> > Björn
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Markus Slopianka 


> On 2010-08-23 09:00:48, Marco Martin wrote:
> > this very patch appeared here for several times already.
> > and as usual, the question is: what real value gives over auto hiding the 
> > text when there is not enough space?

If this patch works with the other one that implements launcher support, a Mac 
OS X-like Dock (AFAIK it's similar in Win7) can be implemented without the need 
to get 3rd party widgets.
With a Dock-like setup I wouldn't want text other than tooltips.


- Markus


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


On 2010-08-22 13:52:33, Björn Ruberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5078/
> ---
> 
> (Updated 2010-08-22 13:52:33)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds the option to put the taskbar in an icon-only mode - similar 
> as in Windows 7 . This is an much requested feature in bugzilla.
> It is fairly simple and just using features already existing in the code, 
> adding an m_showIconOnly member to the layout and the abstractitem plus the 
> adaption of the config ui.
> 
> 
> This addresses bug 159480.
> https://bugs.kde.org/show_bug.cgi?id=159480
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasksConfig.ui 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.cpp
>  1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.h 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 
> 1166313 
> 
> Diff: http://reviewboard.kde.org/r/5078/diff
> 
> 
> Testing
> ---
> 
> Moved panel around and made sure it works. Looks actually pretty good this 
> icon-only mode!
> 
> 
> Thanks,
> 
> Björn
> 
>

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

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Beat Wolf 


> On 2010-08-23 09:00:48, Marco Martin wrote:
> > this very patch appeared here for several times already.
> > and as usual, the question is: what real value gives over auto hiding the 
> > text when there is not enough space?
> 
> Markus Slopianka wrote:
> If this patch works with the other one that implements launcher support, 
> a Mac OS X-like Dock (AFAIK it's similar in Win7) can be implemented without 
> the need to get 3rd party widgets.
> With a Dock-like setup I wouldn't want text other than tooltips.

i would actually agree on adding it from the feedback i get when i show kde to 
people used to windows. it's one of the first things they ask for.


- Beat


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


On 2010-08-22 13:52:33, Björn Ruberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5078/
> ---
> 
> (Updated 2010-08-22 13:52:33)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds the option to put the taskbar in an icon-only mode - similar 
> as in Windows 7 . This is an much requested feature in bugzilla.
> It is fairly simple and just using features already existing in the code, 
> adding an m_showIconOnly member to the layout and the abstractitem plus the 
> adaption of the config ui.
> 
> 
> This addresses bug 159480.
> https://bugs.kde.org/show_bug.cgi?id=159480
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasksConfig.ui 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.cpp
>  1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.h 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 
> 1166313 
> 
> Diff: http://reviewboard.kde.org/r/5078/diff
> 
> 
> Testing
> ---
> 
> Moved panel around and made sure it works. Looks actually pretty good this 
> icon-only mode!
> 
> 
> Thanks,
> 
> Björn
> 
>

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

Re: Need assistance on bug #224666

2010-08-23 Thread Sebastian Kügler 
You'll probably have better chances of success on the plasma-devel list 
therefore CC:ing.

On Saturday 21 August 2010 12:36:53 Sharuzzaman Ahmat Raslan wrote:
> Hi all,
> 
> I need your  assistance to provide me with the question that I have
> written in https://bugs.kde.org/show_bug.cgi?id=224666
> 
> Let me write it again.
> 
> This bug was still present in version 4.4.5-1 in Debian Squeeze.
> 
> As Squeeze was freezed to become Stable release soon, it is important
> that this bug was really fixed in Squeeze.
> 
> Debian KDE team in uncertain which commit is the real fix. If it can
> be identified, I can suggest to them to cherry pick the fix and apply
> it to Debian's source.
> 
> Please let me know the commit number, or appreciate your comment on
> Debian bug report related to this issue at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564941
> 
> Thanks.
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

-- 
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: Need assistance on bug #224666

2010-08-23 Thread Sharuzzaman Ahmat Raslan 
Thank you Sebastian.

I have subscribed to plasma-devel


Hi Plasma-devel team,

Appreciate your input on my email below.

Thanks.



On Mon, Aug 23, 2010 at 7:03 PM, Sebastian Kügler  wrote:
> You'll probably have better chances of success on the plasma-devel list
> therefore CC:ing.
>
> On Saturday 21 August 2010 12:36:53 Sharuzzaman Ahmat Raslan wrote:
>> Hi all,
>>
>> I need your  assistance to provide me with the question that I have
>> written in https://bugs.kde.org/show_bug.cgi?id=224666
>>
>> Let me write it again.
>>
>> This bug was still present in version 4.4.5-1 in Debian Squeeze.
>>
>> As Squeeze was freezed to become Stable release soon, it is important
>> that this bug was really fixed in Squeeze.
>>
>> Debian KDE team in uncertain which commit is the real fix. If it can
>> be identified, I can suggest to them to cherry pick the fix and apply
>> it to Debian's source.
>>
>> Please let me know the commit number, or appreciate your comment on
>> Debian bug report related to this issue at
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564941
>>
>> Thanks.
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<
>
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>



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

Re: Review Request: Extend FolderView::configChanged() to reload configuration values

2010-08-23 Thread Sebastian Kügler 
On Sunday 22 August 2010 19:44:36 Harald Sitter wrote:
> /trunk/KDE/kdebase/apps/plasma/applets/folderview/folderview.cpp  (Diff
> revision 7) void FolderView::init()
>   444
>  const QList iconSizes = QList() << 16 << 22 << 32 << 48 <<
> 64 << 128; This is duplicated with configAccepted!
> 
> Due to what this variable actual represents I do not find it wise to have
> two occurances of the same list. Instead it should be turned into
> something static const or a macro if absolutely necessary.

Look at KIconLoader instead of hardcoding these values.
-- 
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: Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

2010-08-23 Thread Diego Moya 
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 the kdegames module. In the
> > beginnings of the design process, I've identified as a main weakness of
> our
> > applications the fact that they are designed for mouse and keyboard
> > interaction and for desktop form factors. They do not scale to the mobile
> > form-factors which are becoming increasingly important in casual gaming.
>
> > This effort should also cover input methods, in order
> > to make it dead-easy to integrate multitouch support in existing
> > applications.
>
> for input, basically if you are chained to single touch, mouse events are
> usually mostly good enough, if you want to react to multi touch you should
> implement -also- TouchEvents, that have a semantics almost identical to
> mouse
> events, apart that they have an arbitrary number of points in a single
> event.
> there are also higher level gestures, but are probably -too- high level to
> be
> used in games...
>


The problem with mouse events is that they were created for point-and-click
applications in desktop environments, and they don't always translate well
to mobile devices. Events like on-hover or keypress are quite difficult to
reproduce in touch screens. Games aggravate this problem, as they can
introduce a wide variety of interactions.

Have also in mind that other non-standard input devices will likely become
more popular, such as accelerometers, pressure and proximity sensors, or
position tracking (now found at the Wii, Microsoft Natal and PS3 Move).
These will be frequently used in casual games as they get added to mobile
devices, and open games would greatly benefit from a library providing a
standardized way to access them.

For low level interaction that supports all those devices, I'd recommend
basing the APIs on the concept of crossing-based interfaces[1] which have
been poorly supported in traditional widget toolkits, but which I think
would make a good basis for touch and position-based interfaces. A
cross-based interface keeps track not just of the pointed object, but also
which lines are being crossed by the input gesture.

Imagine what a game could do if, instead of a mouse-out event, it received
an event saying "the pointer has exited the button with direction 38º
NorthEast and at a speed of 20 in/s". In my opinion, this mid-level API
would make it easier to program games tailored to several different
input/output methods.


* [1] http://en.wikipedia.org/wiki/Crossing-based_interface
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Martin Gräßlin 
On Monday 23 August 2010 11:53:03 Markus Slopianka wrote:
> > On 2010-08-23 09:00:48, Marco Martin wrote:
> > > this very patch appeared here for several times already.
> > > and as usual, the question is: what real value gives over auto hiding
> > > the text when there is not enough space?
> 
> If this patch works with the other one that implements launcher support, a
> Mac OS X-like Dock (AFAIK it's similar in Win7) can be implemented without
> the need to get 3rd party widgets. With a Dock-like setup I wouldn't want
> text other than tooltips.
Please note that we cannot do proper docks in KDE yet (for various reasons 
related to the way we have X and windows and apps as totally different 
concepts). Windows can't do it as well. They ended up with something horrible 
broken in Win7. So for me it is clear: KDE *must* not ship a dock like 
implementation in the default set. For every body coming from Mac and knowing 
the "real" dock  it will just be: "that sucks" and for everybody coming from 
Windows it's "they copied". Both is bad and gives us no additional value 
except making a vocal minority quiet.

I think we went quite good up to now with "use stasks/fancytasks when you want 
dock". For me it's natural that we don't include broken concepts by default 
and that we ask the user to install the broken concept explicitly when they 
want to.


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: Need assistance on bug #224666

2010-08-23 Thread Chani 

> >> 
> >> I need your  assistance to provide me with the question that I have
> >> written in https://bugs.kde.org/show_bug.cgi?id=224666
> >> 
> >> Let me write it again.
> >> 
> >> This bug was still present in version 4.4.5-1 in Debian Squeeze.
> >> 

hmmm. did you try clearing /var/tmp/ ?

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

Re: [compiz] [RFC] Draft for a compositing manager specification

2010-08-23 Thread Aaron J. Seigo 
On Saturday, August 21, 2010, Carsten Haitzler wrote:
> On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin
> (btw - e17 has had a gl and software compositor for a little while now :)
> if you include bling - a xrender one for many years, so i'm in the
> same/similar boat with you guys, but with a difference - same compositor
> works in both software fallback client-side mode, opengl, with and without
> texture-from-pixmap AND works in opengl-es2.0 so in some ways. just for

this isn't much different from kwin.
 
> 1. properties on root listing what is supported. fine - but big hole. no
> way to know if properties are valid. if cm crashes/exits and leaves them
> there, they will be stale and invalid. need a validity check mechanism
> much like netwm - or stick them on the validity check window (see netwm

good point..
 
> 2. i pretty much have to say no to most of the spec - it's HIGHLY specific.

probably because the apps that need these effects have highly specific needs 
knowable only from witin the app.
 
> 3. the "slide" interaction imho is way too basic and limiting. let's stand
> back and think. what you are asking is for the cm to become a generic
> effects engine with a bunch of apis for very specific effects that you
> control in pretty raw detail. the api is a property on a window as such.
> let's stand back here and turn this into something doable. let's combine
> this with the above visual hints atom. let's add another type atom to the
> visual hints list:
>   TRANSITION <- highly suggested you transition this window in (or out on
> hide) somehow (fade, zoom, flip, slide, whatever). in additionally an
> extra property will provide a suggested "source" for the transition.
> discussed next.

while i'm fine with making the animations more semantic ("transition in") 
rather than specific ("slide in"), we then end up with issues of 
configuration. "transition in" would have to be a one-size-fits-all-windows 
effect otherwise we end up with windows requesting what kind of transition, 
client-side configuration of these things ... not good.

this would give us a way to implement a requested feature: that panels fade in 
rather than slide in, without annoying the rest of the world who prefers 
sliding. i'm not sure it really matters all that much, though, to be honest. i 
suppose this is mostly for different window managers to do things differently 
from each other.

> 4. a transition source property on the client window. TRANSITION_SOURCE is
> a hint as to a "source window id + optional rectangle within that window
> that this one may come from. property format is CARD32 with the elements
> being: [SOURCE WINDOW ID] <- required. may be root window id or any other
> window id on screen. the geometry of this source window id is used as the
> source of the transition hint UNLESS another 4 members of the property (5
> CARD32's instead of 1 total) are provided.
>   [[X],[Y],[WIDTH],[HEIGHT]] <- optional extra 4 CARD32 members that define
> a rectangle (top-left at 0,0 in source window id, all CARD32's are signed
> 32bit integers and width and height must be greater or equal to 0 (values
> less than 0 are reserved for future meanings).

in which circumstances would a rectangular part of the window be a sensible 
thing to apply an effect to? in my experience, it's either the whole window or 
a shape, but rarely if ever an internal rectangle.

the only time we currently use such a target rect is for effects on other 
windows, such as to animate a window on minimize/restore to/from the relevent 
tasks widget.

> 5. EFFECT_NOW atom property. this is a property on a window that contains 0
> or more values of type ATOM (32bit) that request an effect to be applied
> on the given client window. highlight, unimportant, urgent etc. etc - yes
> i know this overlaps netwm. i'm not totally done thinking this over, but
> it's me trying to do your "highlight windows" thing in a more generic way
> where a client requests to be made visually prominent (or the opposite) at
> some point.

highlight windows is currently used by things like the window listing / tasks 
widgets / taskbar to show specific windows. it's not actually related to the 
netwm behaviours. perhaps the naming could be better, or documented clearer.

> 6. present windows... i think this just is better left to be entirely up to
> the cm+wm to do at its leisure. the only thing i'd suggest here is perhaps
> the cm being nice to external processes that want to do ushc "task
> manager" things - same with window preview etc. etc. - cm sets a property
> on the frame window with the current pixmap id of the
> composited/redirected pixmap. any client can pick up this property and the
> pixmap id, and follow the property as it changes to implement this
> themselves in whatever way they want using the pixmap id. (the window its
> on itself provides for visual id and thus argb vs traditional "solid"
> pixmaps).

and then we end up implementing placement and movement log

Re: Review Request: Game of Life Plasmoid -- Cleanup and reflection/density feature addition

2010-08-23 Thread the . goofeedude 

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

(Updated 2010-08-23 19:12:21.184543)


Review request for Plasma.


Changes
---

The updated diff is built on top of the bugfix which was submitted as 1166819 
in trunk (http://reviewboard.kde.org/r/5055/)

Also included in the updated diff are member variable renamings (prepending m_ 
to member variable names.)


Summary (updated)
---

Update (8/23/10): The patch adds two new features to the life applet: game 
board reflection (the user can choose to generate initial populations that are 
symmetrical about the horizontal and/or vertical axes,) and user-configurable 
population density (the user can choose what approximate percentage of cells 
will be alive in the initial population.)

With the addition of the new configuration options, the configuration UI was 
also updated so that using tab to scroll through options would be consistent 
(top to bottom.)

This submit also includes member variable renamings (prepending m_ to member 
variable names.)


Diffs (updated)
-

  /trunk/KDE/kdeplasma-addons/applets/life/life.h 1166777 
  /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1167084 
  /trunk/KDE/kdeplasma-addons/applets/life/lifeConfig.ui 1166777 

Diff: http://reviewboard.kde.org/r/5027/diff


Testing
---

Various game board sizes were tested (odd and even heights and widths, square 
and non-square.) The configuration dialog was opened several times and tested 
to confirm tab order.

Various population densities were tested, including 0% (confirmed no cells were 
alive) and 100% (confirmed that all cells were alive.)

All combinations of vertical/horizontal/no reflection were tested at odd and 
even heights and widths, square and non-square.

Tests consisted of setting the proper configuration options, then watching the 
board for a few generations and confirming that no crashes occurred and that 
all cells appeared to live and die properly. 


Screenshots
---

Updated Configuration Dialog
  http://reviewboard.kde.org/r/5027/s/481/
Board Using Vertical and Horizontal Reflection
  http://reviewboard.kde.org/r/5027/s/482/


Thanks,

obby

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

Re: [Kde-games-devel] Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

2010-08-23 Thread Aaron J. Seigo 
On Sunday, August 22, 2010, Stefan Majewsky wrote:
> Interestingly, I have just now written kdegames' own SVG rendering,
> painting and caching system, with all bells and whistles. (Ask api.kde.org
> for KGameRenderer.) The use case is different:
> * Plasma uses a theme composed of multiple SVG files, AFAIK to be able to
> fallback to the default theme when some of these SVG aren't available. OTOH
> our games use a single SVG theme which contains all visual components.

Marco already answered this a bit, but let me go into more detail:

Plasma::Theme represents a collection of 1 or more SVG documents; it 
simplifies asking for "the svg file named foo". you set the theme to use 
globally, and everything that asks for "the svg file named foo" gets the right 
one. this is obviously saves less work for an app that uses only one svg file 
versus several, but it does nicely abstract away the idea of "different 
themes", which is indeed something that the KDE games support.

i'd also note that there is a limit to the performance to be gained from 
having just one big SVG file, and you are sometimes better off splitting 
things up, depending on the number and complexity of the elements.

there's also the issue of consistency between the games; if there were 
sharable SVG elements, it would be nice to use a more comprehensive theming 
system that allowed layering of partial (game specific) theme files over / 
along side global SVG files, thereby allowing those global files to be used by 
all the KDE games. i don't know if there are any such opportunities for re-
use, and if not, then there's no point to this.

the one other thing that Theme provides Plasma is a convenient place to keep 
the central caching of rendered pixmaps for all Svg objects (or other items 
needing some sort of extra-scene caching). this placement is more a matter of 
convenience, however, rather than a requirement.

> * Plasma::Svg seems to be the lowest granularity of theme components.
> KGameRenderer has the KGameRendererClient which is attached to a single SVG
> element, and receives a new pixmap automatically, should the need arise.

there are, as Marco noted, two classes: Plasma::Svg and Plasma::FrameSvg. 
FrameSvg adds the idea of a "box" made up of 9 different elements and the 
ability to have elements for different edges of the UI (allowing, e.g. for 
lighting hints to be different for one drawn on the right versus the bottom of 
the window/screen/view).

Svg itself allows one to access individual elements. in fact, this is the most 
common method of usage. the elements can be connected to a Plasma::SvgWidget 
which can then update automatically when the Svg does.

one could add a non-painting object like KGameRendererClient that does what 
SvgWidget does (minus the painting :) in under 20 lines of code. the only 
benefit i can think of in doing that would be to create objects that represent 
a given element and handing them to a painting object so that the painting 
object doesn't need to know the name of the element it is painting; besides 
improved encapsulation in that pattern, this could be useful in the case where 
the element object is passed around between painting objects over time, 
allowing the details of "which Svg element id and which Svg" to be ignored.

> * While Plasma renders (AFAIK) nearly its complete UI from these themes,
> games consist of a relatively small number of sprites.

no, Plasma renders portions of its UI from various elements in various Svgs. 
some of these portions take the form of QGraphicsProxyWidgets that have nice 
theming, other portions are simply drawn from the Svg elements (the analog 
clock and the new monochrome system tray widgets, as two different kinds of 
examples), and all of those bits are then put together in the scene.

there's actually far less difference than one might expect between, say, the 
average panel in Plasma Desktop and a KDE game in this respect :)

> Progress bars etc.
> are (if at all) simple QWidgets. Of course, if we want to move everything
> into the themed game view, we will have to theme these elements, but I
> think that QML is a much more likely candidate there.

QML doesn't magically give you themed widgets. you still have to provide them. 
libplasma does exactly that for you.

> > it's also possible to write games as plasmoids and run them in a window.
> > bonus is that we'd get the ability to house all games in a plasma shell,
> > which could be nice on mobile/touch devices for integration purposes. for
> > games that are already QGraphicsView based, this should be relatively
> > trivial. for others, it could be a lot of work.
> 
> Most of our games are QGV-based (a current dataset is at [2]), but quite
> some of them do funny things with the view to implement the scaled
> contents. This makes it at least non-trivial to port them to a view-less
> environment like a plasmoid.

yes and no.

if the assumption is that they own the view, then yes, it isn't going to

Re: QtJolie and remote widgets

2010-08-23 Thread Aaron J. Seigo 
On Saturday, August 21, 2010, Dario Freddi wrote:
> However, I'd really like to remove that code from kdelibs as it definitely
> does not belong there. However, after a quick look at the code, I found out
> that such a thing would mean having a hard dependency on QtJolie in
> kdelibs.

right now, yes, but that would be easily resolved by making those code paths 
conditional. that could be achieved through ifdef's or by abstracting out the 
backend more if needed.
 
> So, basically I'd like to know if anybody is planning to maintain remote
> widgets actively to plan what I should do. I am surely fond to learn Jolie
> as I'm interested in it, so I can volunteer for at least having a better
> situation than now.

awesome :) go head, imho. there was one GSoC student working with QtTelepathy 
who was hoping to make remote widgets work over telepathy tubes. other than 
that, i think it's a wide-open area for work to be done.

> What I'd like to do is abstract the Jolie stack to let kdelibs compile
> without QtJolie itself (even if this would mean remote widgets won't
> really work). 

yes, that would be fine; it would just mean that Applet wouldn't show the 
share dialog and widgets announced on the network wouldn't show up in such a 
build. it should be pretty much completely transparent to the outside world 
without anything looking too ugly.

> I also remember some people talking about abstracting dnssd
> for using $something else, but I'll leave this for the discussion.

yes, that would also be nice (though a different topic), and is what the GSoC 
student would have needed to work on. i don't think he actually got that far, 
however? anyways, abstracting that out was something that was taken into 
consideration in the original design (which is why it is a bit more complex 
than it probably really needs to be a couple of places internally).

-- 
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: spacing between ui components

2010-08-23 Thread Aaron J. Seigo 
On Sunday, August 22, 2010, G VM wrote:
> Anyone an idea how I can fix this?

have you tried setting a size policy on the icon widget?

-- 
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: Review Request: Launcher support for libtaskmanager

2010-08-23 Thread Aaron Seigo 

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



/trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp


if the item is guaranteed to be a LauncherItem, just use a static_cast 
(faster than a qobject_cast, and doesn't imply that it might be something else)



/trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h


following the naming conventions:

GroupItemType,
LauncherItemType,
TaskItemType




/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


const QString



/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


probably a bit faster to do:

taskClass.compare(launcher->name(), Qt::CaseInsensitive) == 0

since that prevents a copy of the string being made. it would also make the 
above toLower() unnecessary.



/trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp


the result of qobject_cast isn't checked and the item is guaranteed to be a 
launcher, so a static_cast is enough (and faster) here



/trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp


the result of qobject_cast isn't checked and the item is guaranteed to be a 
launcher, so a static_cast is enough (and faster) here


- Aaron


On 2010-08-22 10:39:29, Anton Kreuzkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4585/
> ---
> 
> (Updated 2010-08-22 10:39:29)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Adds support for Windows 7 like launchers in libtaskmanager.
> (I'm on holliday from 12th July until 1st August so I will not be able to 
> reply during this time.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/alphasortingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/kustodiangroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
>  1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskactions.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1148442 
> 
> Diff: http://reviewboard.kde.org/r/4585/diff
> 
> 
> Testing
> ---
> 
> Tested with a small test-applett and everything works.
> 
> 
> Thanks,
> 
> Anton
> 
>

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

Re: Review Request: Launcher support for libtaskmanager

2010-08-23 Thread Aaron Seigo 


> On 2010-07-13 20:53:40, Aaron Seigo wrote:
> > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp, lines 264-269
> > 
> >
> > why are launchers with no window instances removed from the member list?
> 
> Anton Kreuzkamp wrote:
> isVisible() returns true if there's no window instance, so it get removed 
> if there is one.

ah! ok, that makes sense ... very unfortunate that this needs to be done on 
each request for members(), however, as that gets called fairly often. it would 
be a lot nicer if the launcher was only added (pre-pended?) to the list if 
there were no windows (and so it should be shown). this could be achieved by 
checking isVisible on the launcher item after calls to addWindowInstance and 
removeWindowInstance; a separate list/set of all launchers would need to be 
kept in this case (for the ones that are !isVisibe and therefore no longer in 
the main list), but this should prevent a lot of iteration, temporary list 
creation, casting and comparisons whenever members() is called.

(another more complex approach might be to make LauncherItem change its type: 
when there are no associated windows it is a launcher item; when there is one 
window, it is a window item; where there is >1 window, it is a group item. 
this, however, is signficantly more complex and not at all worth it as far as i 
can see.) 

(this also implies that once the app is launched, it doesn't make sense to 
launch it again (which isn't always the case), but that's probably ignorable.)


- Aaron


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


On 2010-08-22 10:39:29, Anton Kreuzkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4585/
> ---
> 
> (Updated 2010-08-22 10:39:29)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Adds support for Windows 7 like launchers in libtaskmanager.
> (I'm on holliday from 12th July until 1st August so I will not be able to 
> reply during this time.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/alphasortingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/kustodiangroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
>  1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskactions.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1148442 
> 
> Diff: http://reviewboard.kde.org/r/4585/diff
> 
> 
> Testing
> ---
> 
> Tested with a small test-applett and everything works.
> 
> 
> Thanks,
> 
> Anton
> 
>

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

Re: Review Request: Launcher support for libtaskmanager

2010-08-23 Thread Anton Kreuzkamp 


> On 2010-07-13 20:53:40, Aaron Seigo wrote:
> > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp, lines 264-269
> > 
> >
> > why are launchers with no window instances removed from the member list?
> 
> Anton Kreuzkamp wrote:
> isVisible() returns true if there's no window instance, so it get removed 
> if there is one.
> 
> Aaron Seigo wrote:
> ah! ok, that makes sense ... very unfortunate that this needs to be done 
> on each request for members(), however, as that gets called fairly often. it 
> would be a lot nicer if the launcher was only added (pre-pended?) to the list 
> if there were no windows (and so it should be shown). this could be achieved 
> by checking isVisible on the launcher item after calls to addWindowInstance 
> and removeWindowInstance; a separate list/set of all launchers would need to 
> be kept in this case (for the ones that are !isVisibe and therefore no longer 
> in the main list), but this should prevent a lot of iteration, temporary list 
> creation, casting and comparisons whenever members() is called.
> 
> (another more complex approach might be to make LauncherItem change its 
> type: when there are no associated windows it is a launcher item; when there 
> is one window, it is a window item; where there is >1 window, it is a group 
> item. this, however, is signficantly more complex and not at all worth it as 
> far as i can see.) 
> 
> (this also implies that once the app is launched, it doesn't make sense 
> to launch it again (which isn't always the case), but that's probably 
> ignorable.)

If I didn't missunderstood the code (please correct me if I did) it this only 
gets called if the item wasn't there before (in addTask(); removeTask() only 
gets called if the item really should be removed ) because of this is checked 
before. ("if (!item) {",l.269)


- Anton


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


On 2010-08-22 10:39:29, Anton Kreuzkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4585/
> ---
> 
> (Updated 2010-08-22 10:39:29)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Adds support for Windows 7 like launchers in libtaskmanager.
> (I'm on holliday from 12th July until 1st August so I will not be able to 
> reply during this time.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/alphasortingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/kustodiangroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
>  1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskactions.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1148442 
> 
> Diff: http://reviewboard.kde.org/r/4585/diff
> 
> 
> Testing
> ---
> 
> Tested with a small test-applett and everything works.
> 
> 
> Thanks,
> 
> Anton
> 
>

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

Re: Review Request: Launcher support for libtaskmanager

2010-08-23 Thread Aaron Seigo 


> On 2010-07-13 20:53:40, Aaron Seigo wrote:
> > /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp, lines 264-269
> > 
> >
> > why are launchers with no window instances removed from the member list?
> 
> Anton Kreuzkamp wrote:
> isVisible() returns true if there's no window instance, so it get removed 
> if there is one.
> 
> Aaron Seigo wrote:
> ah! ok, that makes sense ... very unfortunate that this needs to be done 
> on each request for members(), however, as that gets called fairly often. it 
> would be a lot nicer if the launcher was only added (pre-pended?) to the list 
> if there were no windows (and so it should be shown). this could be achieved 
> by checking isVisible on the launcher item after calls to addWindowInstance 
> and removeWindowInstance; a separate list/set of all launchers would need to 
> be kept in this case (for the ones that are !isVisibe and therefore no longer 
> in the main list), but this should prevent a lot of iteration, temporary list 
> creation, casting and comparisons whenever members() is called.
> 
> (another more complex approach might be to make LauncherItem change its 
> type: when there are no associated windows it is a launcher item; when there 
> is one window, it is a window item; where there is >1 window, it is a group 
> item. this, however, is signficantly more complex and not at all worth it as 
> far as i can see.) 
> 
> (this also implies that once the app is launched, it doesn't make sense 
> to launch it again (which isn't always the case), but that's probably 
> ignorable.)
> 
> Anton Kreuzkamp wrote:
> If I didn't missunderstood the code (please correct me if I did) it this 
> only gets called if the item wasn't there before (in addTask(); removeTask() 
> only gets called if the item really should be removed ) because of this is 
> checked before. ("if (!item) {",l.269)

yes, that's correct. however, that is enough to know when a LauncherItem should 
or should not be shown. some possible aproaches:

* LauncherItem could emit a signal when the count drops to zero or becomes 
non-zero, allowing the TaskGroup to connect to this signal and add/remove it 
from the list of items only when it changes

* in LauncherItem::addWindowInstance and LauncherItem::removeWindowInstance, 
something like this:

if (parentGroup() {
parentGroup()->launcherStatusChanged(this);
}

a matter of taste which is more pleasant. personally, i'd go for the latter; 
the signal would be "cleaner" if it weren't for the fact that managing the 
connections and disconnections would be required and the current code probably 
doesn't lend itself to that.


- Aaron


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


On 2010-08-22 10:39:29, Anton Kreuzkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4585/
> ---
> 
> (Updated 2010-08-22 10:39:29)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Adds support for Windows 7 like launchers in libtaskmanager.
> (I'm on holliday from 12th July until 1st August so I will not be able to 
> reply during this time.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
> 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/alphasortingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/kustodiangroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp
>  1148442 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp
>  1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskactions.cpp 1148442 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1166310 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1166

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Aaron Seigo 


> On 2010-08-23 09:00:48, Marco Martin wrote:
> > this very patch appeared here for several times already.
> > and as usual, the question is: what real value gives over auto hiding the 
> > text when there is not enough space?
> 
> Markus Slopianka wrote:
> If this patch works with the other one that implements launcher support, 
> a Mac OS X-like Dock (AFAIK it's similar in Win7) can be implemented without 
> the need to get 3rd party widgets.
> With a Dock-like setup I wouldn't want text other than tooltips.
> 
> Beat Wolf wrote:
> i would actually agree on adding it from the feedback i get when i show 
> kde to people used to windows. it's one of the first things they ask for.

the number of such features that have appeared over the years is immense, and 
always people ask for those features ... as long as they are new in Windows. 
there is no point in chasing taillights just to chase taillights. if the idea 
is a good one, let's do it; if it isn't, let's not.


- Aaron


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


On 2010-08-22 13:52:33, Björn Ruberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5078/
> ---
> 
> (Updated 2010-08-22 13:52:33)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds the option to put the taskbar in an icon-only mode - similar 
> as in Windows 7 . This is an much requested feature in bugzilla.
> It is fairly simple and just using features already existing in the code, 
> adding an m_showIconOnly member to the layout and the abstractitem plus the 
> adaption of the config ui.
> 
> 
> This addresses bug 159480.
> https://bugs.kde.org/show_bug.cgi?id=159480
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasksConfig.ui 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskitemlayout.cpp 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.h 
> 1166313 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/abstracttaskitem.cpp
>  1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.h 
> 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/taskgroupitem.cpp 
> 1166313 
> 
> Diff: http://reviewboard.kde.org/r/5078/diff
> 
> 
> Testing
> ---
> 
> Moved panel around and made sure it works. Looks actually pretty good this 
> icon-only mode!
> 
> 
> Thanks,
> 
> Björn
> 
>

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

Re: Review Request: Add "Show Icon only" option to the tasks applet

2010-08-23 Thread Aaron J. Seigo 
(please keep future discussions on reviewboard, so we aren't chasing half the 
thread here via email and half on reviewboard... :)

On Monday, August 23, 2010, Björn Ruberg wrote:
> > this very patch appeared here for several times already.
> > and as usual, the question is: what real value gives over auto hiding the
> > text when there is not enough space?
> 
> It makes grouping - what increases the amount of clicks you need to get to
> your application by one - unnecessary. 

or you could turn grouping off.

> You can usually see what
> applications are running because you have to look at some icons only
> instead of having to look at the whole panel width.

which some will be happy with, but certainly doesn't help me with my four 
kontact windows, three konsole windows and two firefox windows. :)

> The later often needs
> eye movements (depends on your screen). It's much more appealing to have
> just an icon instead of a task- item with a much shortened window title in
> it.

yes, it's mostly aesthetic. which isn't a bad thing in-and-of-itself. but in 
this case it means requiring another option in the default user interface, and 
this dialog is already fairly full. i'd rather reserve future additions to it 
for actually useful things.

for more dock-like behaviour, i completely agree with Martin G.: use a 
different widget.

i'd personally even be happy with a different style of tasks widget in 
kdeplasma-addons that did funky things like "icons only" or other fun things, 
as long as it was reasonably well done from a user's POV (so: not a random 
collection of dozens of configuration items, no half-baked presentation in the 
widget itself). it would require thinking about the design of the thing: what 
would make it unique, interesting, compelling to use?

kasbar was a good example of such a "outside the regular box" applet back in 
kicker's day. i'd much rather see more separate widgets tuned to different 
kinds of workflows than us try to cram every possible feature into just one 
widget, turning it into a usability and maintenance nightmare than nobody is 
ever 100% happy with.

-- 
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: [compiz] [RFC] Draft for a compositing manager specification

2010-08-23 Thread The Rasterman 
On Mon, 23 Aug 2010 12:09:34 -0700 "Aaron J. Seigo"  said:

> On Saturday, August 21, 2010, Carsten Haitzler wrote:
> > On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin
> > (btw - e17 has had a gl and software compositor for a little while now :)
> > if you include bling - a xrender one for many years, so i'm in the
> > same/similar boat with you guys, but with a difference - same compositor
> > works in both software fallback client-side mode, opengl, with and without
> > texture-from-pixmap AND works in opengl-es2.0 so in some ways. just for
> 
> this isn't much different from kwin.

aaah ok. cool.

> > 1. properties on root listing what is supported. fine - but big hole. no
> > way to know if properties are valid. if cm crashes/exits and leaves them
> > there, they will be stale and invalid. need a validity check mechanism
> > much like netwm - or stick them on the validity check window (see netwm
> 
> good point..

:)

> > 2. i pretty much have to say no to most of the spec - it's HIGHLY specific.
> 
> probably because the apps that need these effects have highly specific needs 
> knowable only from witin the app.

that's generally a problem for a general spec... generally... :)

> > 3. the "slide" interaction imho is way too basic and limiting. let's stand
> > back and think. what you are asking is for the cm to become a generic
> > effects engine with a bunch of apis for very specific effects that you
> > control in pretty raw detail. the api is a property on a window as such.
> > let's stand back here and turn this into something doable. let's combine
> > this with the above visual hints atom. let's add another type atom to the
> > visual hints list:
> >   TRANSITION <- highly suggested you transition this window in (or out on
> > hide) somehow (fade, zoom, flip, slide, whatever). in additionally an
> > extra property will provide a suggested "source" for the transition.
> > discussed next.
> 
> while i'm fine with making the animations more semantic ("transition in") 
> rather than specific ("slide in"), we then end up with issues of 
> configuration. "transition in" would have to be a one-size-fits-all-windows 
> effect otherwise we end up with windows requesting what kind of transition, 
> client-side configuration of these things ... not good.
> 
> this would give us a way to implement a requested feature: that panels fade
> in rather than slide in, without annoying the rest of the world who prefers 
> sliding. i'm not sure it really matters all that much, though, to be honest.
> i suppose this is mostly for different window managers to do things
> differently from each other.

well - i think that you CAN do this with a combo of both. use cm hints as a "do
an effect at all" and use netwm hints (eg netwm window type, combined with
name, class and a bunch of rules to "match stuff") to get all the specific
effects you want your your desktop env. what i'd like is to not have this spec
blow out from "well now we have slide in" then in 6 months "well add zoom in"
then a "flip and fade in" then a "rotate in" then a "explode in" and the list
goes on. i 'd like to stop going down the specific effect path and leave that
up to the cm decide precisely what effects they are, how they work etc. etc.
and have more of a coarse-grained switch  to say "but noo dont do
any of your fancy goop on me!" for example. if it does do "fancy goop" there is
more than enough information in name+class+title+netm window type+wm role and
so on to do this there.

> > 4. a transition source property on the client window. TRANSITION_SOURCE is
> > a hint as to a "source window id + optional rectangle within that window
> > that this one may come from. property format is CARD32 with the elements
> > being: [SOURCE WINDOW ID] <- required. may be root window id or any other
> > window id on screen. the geometry of this source window id is used as the
> > source of the transition hint UNLESS another 4 members of the property (5
> > CARD32's instead of 1 total) are provided.
> >   [[X],[Y],[WIDTH],[HEIGHT]] <- optional extra 4 CARD32 members that define
> > a rectangle (top-left at 0,0 in source window id, all CARD32's are signed
> > 32bit integers and width and height must be greater or equal to 0 (values
> > less than 0 are reserved for future meanings).
> 
> in which circumstances would a rectangular part of the window be a sensible 
> thing to apply an effect to? in my experience, it's either the whole window
> or a shape, but rarely if ever an internal rectangle.
> 
> the only time we currently use such a target rect is for effects on other 
> windows, such as to animate a window on minimize/restore to/from the relevent 
> tasks widget.

ooh i think you mis-understood me. the rect region within the source window is
optional.. and it is the "source" for the effect. eg IF you slide, or soom or
rotate + zoom in - the window as a WHOLE appears to transition "from" this rect
within the source window on screen to its final r