Re: Re: Re: some work and api design on plasma2
On Friday 20 July 2012 00:47:35 Alex Fiestas wrote: > On Thursday 19 July 2012 21:18:50 Marco Martin wrote: > > anybody can think about technical problems about it that may be lurking? > > it may mean a release of the workspace that doesn't use completely > > frameworks, so both old kdelibs and the frameworks will have to be > > distributed for some time, may this be a problem? (but not avoidable > > probably) > > Uh... please don't eat me :) > > Do we really want to support qgv? it is a super big chunk of code we will > have to maintain for, waht gain? > > Pros: > - Keeping compatibility > - Not having to port everything to QML before switching to frameworks > - ... ? > > Cons: > - Big chunk of code to maintain > - QGV dropped by Qt project > - People not porting to QML because QGV work. > - We will piss people off > > How difficult would be to support ? would be possible to keep supporting it > when QML2 come to play? Very big con: users will hate us if we redo a 4.0 in Plasma and dropping QGV before everything is ported would mean doing a 4.0. And if we wait till everything is ported to QML we won't go anywhere. So yes I think we just have to support QGV, whether we like or not. 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: Re: some work and api design on plasma2
On Friday 20 July 2012 01:50:35 Aleix Pol wrote:> > Well, the "only" problem would be that any application using plasma > wouldn't be able to be ported to KF5. not if KF5 contains a libplasma1 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
[KDE Bugtracking System] REMINDER: current Plasma regressions
Please find below a list of the current regressions reported for Plasma This search was scheduled by myr...@kde.org. Plasma regressions -- Bug 291676: https://bugs.kde.org/show_bug.cgi?id=291676 Priority: NOR Severity: normal Platform: Gentoo Packages Assignee: plasma-b...@kde.org Status: NEW Summary: Device Items resize on hover due to visibility change of the status text Bug 301424: https://bugs.kde.org/show_bug.cgi?id=301424 Priority: NOR Severity: normal Platform: openSUSE RPMs Assignee: plasma-b...@kde.org Status: NEW Summary: Cannot open battery monitor applet if set to hidden in systray Bug 301533: https://bugs.kde.org/show_bug.cgi?id=301533 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Option "Show Multiple Batteries" does nothing Bug 303297: https://bugs.kde.org/show_bug.cgi?id=303297 Priority: NOR Severity: normal Platform: Compiled Sources Assignee: plasma-b...@kde.org Status: NEW Summary: Konsole Profiles widget is not usable via keyboard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: some work and api design on plasma2
On Fri, Jul 20, 2012 at 2:47 AM, Alex Fiestas wrote: > On Thursday 19 July 2012 21:18:50 Marco Martin wrote: >> anybody can think about technical problems about it that may be lurking? >> it may mean a release of the workspace that doesn't use completely >> frameworks, so both old kdelibs and the frameworks will have to be >> distributed for some time, may this be a problem? (but not avoidable >> probably) > Uh... please don't eat me :) > > Do we really want to support qgv? it is a super big chunk of code we will have > to maintain for, waht gain? > > Pros: > - Keeping compatibility > - Not having to port everything to QML before switching to frameworks > - ... ? > > Cons: > - Big chunk of code to maintain > - QGV dropped by Qt project > - People not porting to QML because QGV work. > - We will piss people off > > How difficult would be to support ? would be possible to keep supporting it > when QML2 come to play? > > Cheerz ! > > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Well, I really doubt we can do a proper QtQuick1 to QtQuick2 port anyway. They are the same language but very different beasts. Another thing we can do, is to make a plain of libplasma to Qt5 and then create libawesomething where API would be maintained where applies but wouldn't depend on qgv. libplasma+qt5 could serve as a system to adapt to a new API but that's all. When the new one can be adopted then libplasma can be considered as deprecated (like we consider nowadays qgv-based plasmoids). Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some work and api design on plasma2
On Thu, Jul 19, 2012 at 9:18 PM, Marco Martin wrote: > On Thursday 19 July 2012, Martin Gräßlin wrote: >> On Thursday 19 July 2012 20:35:51 Marco Martin wrote: >> > but the most important thing is that kf5 is kinda the last chance for big >> > incompatime changes, at least for a long while. >> >> do we need a libplasma in KF 5.0? Would it be a huge issue to say libplasma >> is split out of frameworks but not released as part of 5.0, but will enter >> in 5.1 or 5.2. Or having a split-out libplasma API compatible might be a >> quite nice thing in fact for 3rd-party applications using Plasma and don't >> want to do heavy porting. Remember KF 5 should be easy to port to, right >> ;-) > > personally, would not be a problem and would give quite some room to breathe > ;) > > anybody can think about technical problems about it that may be lurking? > it may mean a release of the workspace that doesn't use completely frameworks, > so both old kdelibs and the frameworks will have to be distributed for some > time, may this be a problem? (but not avoidable probably) > > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Well, the "only" problem would be that any application using plasma wouldn't be able to be ported to KF5. In any case, I think that in this case it makes sense to foresee a binary breakage like in 1 year. Rushing into this could put us in an unstable place where we've been before. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: back developing [KRunner Bookmarks for chrome]
Well yes, but i don't mean to develop a separate runner, just add chrome support to the existing one (which already supports Firefox and Opera too). And yes, i saw a chrome runner too, but it's a standalone runner. I'll probably still look at it, but the main point is to refactor the existing one first (already done locally, actually) so new browser support can be added more easly. Chrome bookmarks per se are easy to read, it looks like a plain json file. If it's ok I can start pushing refactored code to master starting tomorrow. Cheers On Fri, Jul 20, 2012 at 2:50 AM, Alex Fiestas wrote: > You don't need a branch to develop a runner, you can actually do it in a > separate repo, maybe a kde scratch ? > > Something tells me that I have seen a chrome bookmark runner before... but > maybe I'm wrong (for sure I have seen the firefox one). > > Cheerz ! > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: back developing [KRunner Bookmarks for chrome]
You don't need a branch to develop a runner, you can actually do it in a separate repo, maybe a kde scratch ? Something tells me that I have seen a chrome bookmark runner before... but maybe I'm wrong (for sure I have seen the firefox one). Cheerz ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: some work and api design on plasma2
On Thursday 19 July 2012 21:18:50 Marco Martin wrote: > anybody can think about technical problems about it that may be lurking? > it may mean a release of the workspace that doesn't use completely > frameworks, so both old kdelibs and the frameworks will have to be > distributed for some time, may this be a problem? (but not avoidable > probably) Uh... please don't eat me :) Do we really want to support qgv? it is a super big chunk of code we will have to maintain for, waht gain? Pros: - Keeping compatibility - Not having to port everything to QML before switching to frameworks - ... ? Cons: - Big chunk of code to maintain - QGV dropped by Qt project - People not porting to QML because QGV work. - We will piss people off How difficult would be to support ? would be possible to keep supporting it when QML2 come to play? Cheerz ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fwd: back developing [KRunner Bookmarks for chrome]
Hello! As i've been suggested, forwarding my previous mail in here, since i'm working on plasma files. Thanks Marco -- Forwarded message -- From: Marco Gulino Date: Thu, Jul 19, 2012 at 9:43 AM Subject: back developing [KRunner Bookmarks for chrome] To: kde-devel Hi! I was a developer in KDE area some years ago, had to drop it due to lack of time, hardware, and usual various impediments :P Now i'd like to spend some of my free time helping improving KDE. In particular, i was thinking about adding chrom* support to the Bookmarks runner, plus some refactoring and maybe unit testing. Any objection? also, what about branches? I understand that KDE/4.9 is closed for now, i guess the best thing would be to create my own branch, and then merging to KDE/4.9 and master after 4.9 release. Next, i'm also thinking about fixing a couple of issue in Konsole (profiles management seems to be a bit broken) and KHotKeys, but i'll write more at the right time. Thanks Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some work and api design on plasma2
On Thursday 19 July 2012, Martin Gräßlin wrote: > On Thursday 19 July 2012 20:35:51 Marco Martin wrote: > > but the most important thing is that kf5 is kinda the last chance for big > > incompatime changes, at least for a long while. > > do we need a libplasma in KF 5.0? Would it be a huge issue to say libplasma > is split out of frameworks but not released as part of 5.0, but will enter > in 5.1 or 5.2. Or having a split-out libplasma API compatible might be a > quite nice thing in fact for 3rd-party applications using Plasma and don't > want to do heavy porting. Remember KF 5 should be easy to port to, right > ;-) personally, would not be a problem and would give quite some room to breathe ;) anybody can think about technical problems about it that may be lurking? it may mean a release of the workspace that doesn't use completely frameworks, so both old kdelibs and the frameworks will have to be distributed for some time, may this be a problem? (but not avoidable probably) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Files, config, and welcome (again)
Hi again, Got entangled in a lot of other work, finally getting back to the QML/JS ToDo plasmoid of mine. I still cannot find any docs on accessing the calendar (either directly or through Akonadi) from QML/JS. I would appreciate any hints/links on that - is that at all possible?.. Thanks! -- Pozdrawiam Michał "rysiek" Woźniak Fundacja Wolnego i Otwartego Oprogramowania 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: Re: some work and api design on plasma2
On Thursday 19 July 2012 20:35:51 Marco Martin wrote: > but the most important thing is that kf5 is kinda the last chance for big > incompatime changes, at least for a long while. do we need a libplasma in KF 5.0? Would it be a huge issue to say libplasma is split out of frameworks but not released as part of 5.0, but will enter in 5.1 or 5.2. Or having a split-out libplasma API compatible might be a quite nice thing in fact for 3rd-party applications using Plasma and don't want to do heavy porting. Remember KF 5 should be easy to port to, right ;-) IIRC libplasma had not been part of KDElibs 4.0 either, so I personally see no issue with having a libplasma1 as part of KF 5.0 and later on add a libplasma 2 to 5.1 or 5.2. The disadvantage would be that the namespace would have to be changed from Plasma to Plasma2, but that can also be considered as an advantage... 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: some work and api design on plasma2
On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin wrote:
> Hi all,
>
> as you know the hardest thing, by far in plasma2 is splitting anything related
> to qgraphics* out of libplasma.
> that basically means graphics-less Applet, Containment and Corona, and this
> will have to happen in time for frameworks5, regardless having a qml2 version
> ready or not (i would go as far as putting that as completely secondary and
> eventually releasing it only in a second time)
> the quantity of work still to be done is huge, and the time not much.
>
> i have now a branch in kdelibs: plasma/mart/simpleapplet
>
> it's a branch of frameworks and had the following work:
>
> corona, containment and applet are for now disabled from build (libplsmaqgv
> that's the legacy qgraphics* library doesn't build atm)
> there are AbsrtactApplet and AbstractContainment: they are still not finished,
> but are intended to be qobject-only versions, with only the logic. all the
> other parts in libplasma that were depending from applet or containment are
> now using abstractapplet or abstractcontainment.
>
>
> problem: the old qgv based Applet and Containment should inherit from
> AbstractApplet and AbstractContainment, but this means abstract* cannot be
> QObjects, but they need some signals and slots (besides needing to be able to
> be loaded as plugins: required to be qobject?)
>
> so basically there are 2 options:
> a) abstractapplet/containment are not qobjects (exposing a qobject member for
> needed signals/slots? kinda ugly)
>
> b) make them qobjects and make Applet/Containment not a subclass but having
> abstractapplet as a member property, so that would become a sort of a "model"
> (kinda ugly as well)
>
> in both cases it may be needed and a completely separated implementation of
> Corona (that in turn poses the same problem, at the moment it has a partial
> separation to a CoronaBase class that is following the model b) approach, but
> can be changed)
>
>
> comments? suggestions? volunteers for the work? :p
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
Hi,
Finally something where i can share my knowledge :)
Recently (last week!) i had this issue with inheritance and QObject as
well. I wanted to make an abstract class (an interface actually) with
signals. That last part required QObject and adding that makes t he
compiler go nuts since each implementation would also inherit from
something that has QObject. An example:
class MyInterface : public QObject
{
Q_OBJECT
signals:
virtual void mySignal() =0;
}
class Implementation : public QFile
{
Q_OBJECT
signals:
void mySignal();
}
That fails because QFile also has QObject.
After that i went googling for a while to figure out how i could use
inheritance but somehow avoid this issue.
Turns out that i had to use
Q_DECLARE_INTERFACE
Q_INTERFACES
which was described here:
http://stackoverflow.com/questions/3726716/qt-interfaces-or-abstract-classes-and-qobject-cast/3726868#3726868
With that in mind the above example needs to be written as follows:
class MyInterface // NO QObject inheritance!
{
signals:
virtual void mySignal() =0;
}
Q_DECLARE_INTERFACE(MyInterface, "MyInterface/1.0")
class Implementation : public QFile, public MyInterface
{
Q_OBJECT
Q_INTERFACES(MyInterface)
signals:
void mySignal();
}
That compiles and works. Yet, you still can't use your signals. In
order for the signals to work you can do 2 things now.
1:
casting to QObject like so:
MyInterface* test = new Implementation();
QObject::connect(dynamic_cast(test), SIGNAL(mySignal()), SLOT(...));
2:
By following this http://stackoverflow.com/a/3260487 which results a
signal being done this way (assuming you adjust the MyInterface
according to that answer):
MyInterface* test = new Implementation();
QObject::connect(test->object(), SIGNAL(mySignal()), SLOT(...));
I actually tried the first one (and am using it right now) and that
works well. I haven't tried the second one though.
So there you go, an answer to your question for signals in a abstract
class. Hope that helps.
Good luck,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some work and api design on plasma2
On Thursday 19 July 2012, Aleix Pol wrote: > On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin wrote: > > Hi all, > > > > as you know the hardest thing, by far in plasma2 is splitting anything > > related to qgraphics* out of libplasma. > > that basically means graphics-less Applet, Containment and Corona, and > > this will have to happen in time for frameworks5, regardless having a > > qml2 version ready or not (i would go as far as putting that as > > completely secondary and eventually releasing it only in a second time) > > the quantity of work still to be done is huge, and the time not much. > > > > i have now a branch in kdelibs: plasma/mart/simpleapplet > > > > it's a branch of frameworks and had the following work: > > > > corona, containment and applet are for now disabled from build > > (libplsmaqgv that's the legacy qgraphics* library doesn't build atm) > > there are AbsrtactApplet and AbstractContainment: they are still not > > finished, but are intended to be qobject-only versions, with only the > > logic. all the other parts in libplasma that were depending from applet > > or containment are now using abstractapplet or abstractcontainment. > > > > > > problem: the old qgv based Applet and Containment should inherit from > > AbstractApplet and AbstractContainment, but this means abstract* cannot > > be QObjects, but they need some signals and slots (besides needing to be > > able to be loaded as plugins: required to be qobject?) > > > > so basically there are 2 options: > > a) abstractapplet/containment are not qobjects (exposing a qobject member > > for needed signals/slots? kinda ugly) > > > > b) make them qobjects and make Applet/Containment not a subclass but > > having abstractapplet as a member property, so that would become a sort > > of a "model" (kinda ugly as well) > > > > in both cases it may be needed and a completely separated implementation > > of Corona (that in turn poses the same problem, at the moment it has a > > partial separation to a CoronaBase class that is following the model b) > > approach, but can be changed) > > > > > > comments? suggestions? volunteers for the work? :p > > > > Cheers, > > Marco Martin > > ___ > > Plasma-devel mailing list > > Plasma-devel@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > > Do we really need to have this for KF 5.0? It should keep working with > Qt5, so rushing could be a problem... well, right now what's in frameworks is a quite in between status that is not really working, so has to be brought in a state working without too many regressions. but the most important thing is that kf5 is kinda the last chance for big incompatime changes, at least for a long while. > On the other hand, I agree that it's something we want to have stable ASAP. > > It would be good if someone could step forward and organize a little > bit how this refactoring should happen and what would be the scope of i think basically having two libraries, a libplasma and libplasmaqgv, with libplasma not depending from qgraphicsview. an application linking to libplasmaqgv should maintain at least a good extent of source compatibility with current shells/applets. that opens the possibility of having a libplasmaqml2 in the future, even tough on which i don't really want to think about yet ;) for this basically is quite trivial for most classes, except the usual corona/containment/applet. now i don't know how far from working is my branch, but i guess a quite scary amount of hours is still needed (and in which may not be trivial working in more than one person on it ;) > the port. I might be able to dedicate some time on this, but I must > make sure it's not a time drainer. eh, that's quite a possibility :/ -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some work and api design on plasma2
On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin wrote: > Hi all, > > as you know the hardest thing, by far in plasma2 is splitting anything related > to qgraphics* out of libplasma. > that basically means graphics-less Applet, Containment and Corona, and this > will have to happen in time for frameworks5, regardless having a qml2 version > ready or not (i would go as far as putting that as completely secondary and > eventually releasing it only in a second time) > the quantity of work still to be done is huge, and the time not much. > > i have now a branch in kdelibs: plasma/mart/simpleapplet > > it's a branch of frameworks and had the following work: > > corona, containment and applet are for now disabled from build (libplsmaqgv > that's the legacy qgraphics* library doesn't build atm) > there are AbsrtactApplet and AbstractContainment: they are still not finished, > but are intended to be qobject-only versions, with only the logic. all the > other parts in libplasma that were depending from applet or containment are > now using abstractapplet or abstractcontainment. > > > problem: the old qgv based Applet and Containment should inherit from > AbstractApplet and AbstractContainment, but this means abstract* cannot be > QObjects, but they need some signals and slots (besides needing to be able to > be loaded as plugins: required to be qobject?) > > so basically there are 2 options: > a) abstractapplet/containment are not qobjects (exposing a qobject member for > needed signals/slots? kinda ugly) > > b) make them qobjects and make Applet/Containment not a subclass but having > abstractapplet as a member property, so that would become a sort of a "model" > (kinda ugly as well) > > in both cases it may be needed and a completely separated implementation of > Corona (that in turn poses the same problem, at the moment it has a partial > separation to a CoronaBase class that is following the model b) approach, but > can be changed) > > > comments? suggestions? volunteers for the work? :p > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Do we really need to have this for KF 5.0? It should keep working with Qt5, so rushing could be a problem... On the other hand, I agree that it's something we want to have stable ASAP. It would be good if someone could step forward and organize a little bit how this refactoring should happen and what would be the scope of the port. I might be able to dedicate some time on this, but I must make sure it's not a time drainer. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
some work and api design on plasma2
Hi all, as you know the hardest thing, by far in plasma2 is splitting anything related to qgraphics* out of libplasma. that basically means graphics-less Applet, Containment and Corona, and this will have to happen in time for frameworks5, regardless having a qml2 version ready or not (i would go as far as putting that as completely secondary and eventually releasing it only in a second time) the quantity of work still to be done is huge, and the time not much. i have now a branch in kdelibs: plasma/mart/simpleapplet it's a branch of frameworks and had the following work: corona, containment and applet are for now disabled from build (libplsmaqgv that's the legacy qgraphics* library doesn't build atm) there are AbsrtactApplet and AbstractContainment: they are still not finished, but are intended to be qobject-only versions, with only the logic. all the other parts in libplasma that were depending from applet or containment are now using abstractapplet or abstractcontainment. problem: the old qgv based Applet and Containment should inherit from AbstractApplet and AbstractContainment, but this means abstract* cannot be QObjects, but they need some signals and slots (besides needing to be able to be loaded as plugins: required to be qobject?) so basically there are 2 options: a) abstractapplet/containment are not qobjects (exposing a qobject member for needed signals/slots? kinda ugly) b) make them qobjects and make Applet/Containment not a subclass but having abstractapplet as a member property, so that would become a sort of a "model" (kinda ugly as well) in both cases it may be needed and a completely separated implementation of Corona (that in turn poses the same problem, at the moment it has a partial separation to a CoronaBase class that is following the model b) approach, but can be changed) comments? suggestions? volunteers for the work? :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kickoff-qml: TabBar button width
> On July 19, 2012, 9:04 a.m., Marco Martin wrote: > > thanks, wouldn;t have remembered ;) > > > > the changes seems good, but i'm not sure about giving kickoff a copy of the > > tabbar. > > > > any reason this is not proposed as a patch for the tabbar component itself? > > Greg T wrote: > Of course I could do that. But I didn't know if such a general change > would be welcome. Maybe people love equally sized blocks? i really think we shouldn't start to customize the components in a single applet like that. what could be done is: as implicit width of the tabbar should be a width such that all tabs have the same width that is the one of the largest tab, so by default it would attempt to never elide (probably some work in the bindings is needed to export this as preferred width of the applet). if it's forced to be smaller it starts to elide the text. - Marco --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105405/#review16103 --- On July 1, 2012, 8:42 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105405/ > --- > > (Updated July 1, 2012, 8:42 p.m.) > > > Review request for Plasma, Marco Martin and Martin Gräßlin. > > > Description > --- > > Heda, > This patch addresses the layout of the tab bar. The tab buttons are now sized > depending of their text width. > > I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. > My main question is: Can I do this more elegantly without copying TabBar.qml? > > > Diffs > - > > plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 > > Diff: http://git.reviewboard.kde.org/r/105405/diff/ > > > Testing > --- > > > Thanks, > > Greg T > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kickoff-qml: TabBar button width
> On July 19, 2012, 9:04 a.m., Marco Martin wrote: > > thanks, wouldn;t have remembered ;) > > > > the changes seems good, but i'm not sure about giving kickoff a copy of the > > tabbar. > > > > any reason this is not proposed as a patch for the tabbar component itself? Of course I could do that. But I didn't know if such a general change would be welcome. Maybe people love equally sized blocks? - Greg --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105405/#review16103 --- On July 1, 2012, 8:42 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105405/ > --- > > (Updated July 1, 2012, 8:42 p.m.) > > > Review request for Plasma, Marco Martin and Martin Gräßlin. > > > Description > --- > > Heda, > This patch addresses the layout of the tab bar. The tab buttons are now sized > depending of their text width. > > I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. > My main question is: Can I do this more elegantly without copying TabBar.qml? > > > Diffs > - > > plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 > > Diff: http://git.reviewboard.kde.org/r/105405/diff/ > > > Testing > --- > > > Thanks, > > Greg T > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kickoff-qml: TabBar button width
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105405/#review16118 --- If you ask me, i like the "old" view better with the elided text and fixed width bottons. It looks a bit messy if every button has a different width. Just my 5 cents on this one. - Mark Gaiser On July 1, 2012, 8:42 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105405/ > --- > > (Updated July 1, 2012, 8:42 p.m.) > > > Review request for Plasma, Marco Martin and Martin Gräßlin. > > > Description > --- > > Heda, > This patch addresses the layout of the tab bar. The tab buttons are now sized > depending of their text width. > > I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. > My main question is: Can I do this more elegantly without copying TabBar.qml? > > > Diffs > - > > plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 > > Diff: http://git.reviewboard.kde.org/r/105405/diff/ > > > Testing > --- > > > Thanks, > > Greg T > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kickoff-qml: TabBar button width
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105405/#review16103 --- thanks, wouldn;t have remembered ;) the changes seems good, but i'm not sure about giving kickoff a copy of the tabbar. any reason this is not proposed as a patch for the tabbar component itself? - Marco Martin On July 1, 2012, 8:42 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105405/ > --- > > (Updated July 1, 2012, 8:42 p.m.) > > > Review request for Plasma, Marco Martin and Martin Gräßlin. > > > Description > --- > > Heda, > This patch addresses the layout of the tab bar. The tab buttons are now sized > depending of their text width. > > I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. > My main question is: Can I do this more elegantly without copying TabBar.qml? > > > Diffs > - > > plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 > > Diff: http://git.reviewboard.kde.org/r/105405/diff/ > > > Testing > --- > > > Thanks, > > Greg T > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kickoff-qml: TabBar button width
> On July 3, 2012, 8:34 a.m., Martin Gräßlin wrote: > > please push it again after Akademy - I doubt that I find the time to > > properly read through it in this week well *push* :) any ideas? - Greg --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105405/#review15332 --- On July 1, 2012, 8:42 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105405/ > --- > > (Updated July 1, 2012, 8:42 p.m.) > > > Review request for Plasma, Marco Martin and Martin Gräßlin. > > > Description > --- > > Heda, > This patch addresses the layout of the tab bar. The tab buttons are now sized > depending of their text width. > > I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. > My main question is: Can I do this more elegantly without copying TabBar.qml? > > > Diffs > - > > plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml > PRE-CREATION > plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 > > Diff: http://git.reviewboard.kde.org/r/105405/diff/ > > > Testing > --- > > > Thanks, > > Greg T > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
