> another thing that i wish it was possible that is a bit troublesome at the
> moment is a thing like this part of the mockup that i have not (yet) posted:
> http://wstaw.org/m/2012/06/05/plasma-desktoprK3844.png
This is not that different to the 3D dock. It just needs some
contextual information
On Monday 04 June 2012, Ivan Čukić wrote:
>
> :D )
> :
> >> - visually connecting the popups with the applets
> >>example: http://kde-look.org/CONTENT/content-pre1/53086-1.png
> >>or a 'triangle' pointing to the applet or anything else that people
> >> can devise
> >>(yeah, this is my
Not thinking anymore this has a purpose since, as Marco said, there
are more important things to do. And the API doesn't need to change in
order for us to later change the FSVG.
But, here are the answers... for the record, and as a thought experiment :)
> +1 .. overlay was a neat idea, but i agre
On Monday 04 June 2012, Aaron J. Seigo wrote:
> ways, we can change how theming is done. if it isn't a lot better, then we
> know and we'll feel less bad about the current system and nothing is lost
> except a small amount of time.
>
> libplasma2 is the only time we'll get to dance this dance, so
On Monday, June 4, 2012 20:51:31 Ivan Cukic wrote:
> - non-stretch borders or center
>is there any important theme really using this?
i think one or two themes are ... but we could just settle on or the other and
say "that's how it is now"
> - mask
>ok, this serves some purpose - defines
On Monday 04 June 2012, Ivan Cukic wrote:
> > then let's go through the API and mark which are which so we can plan
> > properly for libplasma2. as you made the assertion, i'd like to ask you
> > go first :)
>
> I don't mind the API of the class that much. That is, the things that it
> provides, I
> yes, a concrete thing that i would do different.. (and i'm not advocating to
> change, because of the retrocompatibility and because there are plenty other
> areas that have more priorities to put work into)
That is true. I'm somehow hoping this will all come free somehow :/
(or we will find som
> then let's go through the API and mark which are which so we can plan
> properly for libplasma2. as you made the assertion, i'd like to ask you go
> first :)
I don't mind the API of the class that much. That is, the things that it
provides, I guess it could be prettier but that's another point
On Monday, June 4, 2012 20:22:45 Marco Martin wrote:
> a probable nice way would be to have the border in a single element then
> have hint rectangles that indicates where to cut the rendered pixmap and
> assemble again in the final result
we could at least try this. and if it is notably better i
On Monday 04 June 2012, Aaron J. Seigo wrote:
> On Monday, June 4, 2012 11:57:09 Marco Martin wrote:
> > there are things that revealed to be pretty painful, like having to have
> > the borders actually splitted in different elements rather than split the
> > rendered pixmap afterwards, having to d
On Monday, June 4, 2012 11:57:09 Marco Martin wrote:
> there are things that revealed to be pretty painful, like having to have
> the borders actually splitted in different elements rather than split the
> rendered pixmap afterwards, having to design the thing from scratch i would
> make it behave
On Monday, June 4, 2012 18:36:32 Ivan ÄukiÄ wrote:
> FrameSvg is awesome, that stands. At the same time it is filled with
> unused features. And misused features :)
then let's go through the API and mark which are which so we can plan properly
for libplasma2. as you made the assertion, i'd like
On Monday, June 4, 2012 11:45:48 Daker Fernandes Pinheiro wrote:
> Exactly, the QStyle painting will be there for retro compatibility and
QML and/or QStyle will get support for desktop panels, popup dialogs, desktop
notifications, window switchers, ... ?
iow: when we say "style" we don't just me
On Monday 04 June 2012, Ivan Čukić wrote:
> FrameSvg is awesome, that stands. At the same time it is filled with
> unused features. And misused features :)
> From my pov, it could be slimmed down for the common use-case, kept
> the current one in the old-theme-compatibility-plugin etc. Aka,
> perfo
FrameSvg is awesome, that stands. At the same time it is filled with
unused features. And misused features :)
>From my pov, it could be slimmed down for the common use-case, kept
the current one in the old-theme-compatibility-plugin etc. Aka,
performance impact only on explicit request.
The issue
On Monday 04 June 2012, Alex Fiestas wrote:
> There are many parties working on the same goal, QML+theming. Imho we
> should join them and work together to an unified solution.
>
> I remember on qt-development mailist someone asking for moving desktop
> components into Qt plauground's, then there
On Monday 04 June 2012, Daker Fernandes Pinheiro wrote:
>
> > as i said, my main concern is that framesvg is used a lot around in qml,
> > so that would require again a new porting effort.
>
> In the proposed architecture [2], the porting effort wouldn't be much
> painful, at least for the Plasma
Hi,
2012/6/4 Marco Martin
> On Monday 04 June 2012, Ivan Čukić wrote:
> > Hi all,
> >
> > With qml-ifying plasma, we have the opportunity to completely break
> > the current theming system and make something that would work. I'm
>
> well, not really, since svg and framesvg are directly binded to
There are many parties working on the same goal, QML+theming. Imho we should
join them and work together to an unified solution.
I remember on qt-development mailist someone asking for moving desktop
components into Qt plauground's, then there are the guys at IndT, everybody
involved on compone
On Monday 04 June 2012, Ivan Čukić wrote:
> Hi all,
>
> With qml-ifying plasma, we have the opportunity to completely break
> the current theming system and make something that would work. I'm
well, not really, since svg and framesvg are directly binded to qml (and quite
heavily used, even outsi
Hi all,
With qml-ifying plasma, we have the opportunity to completely break
the current theming system and make something that would work. I'm
usually all for back-compatibility, but in this case I think we should
start from scratch. We have already had discussions about why the
current theming sy
21 matches
Mail list logo
