Re: "Cornelius's grand plan" - Merging KDElibs into Qt

2010-10-31 Thread John Tapsell
On 31 October 2010 11:33, Mark Kretschmann  wrote:
> Hey all,
>
> after reading the whole thread that started with Chani's mail ("why
> kdelibs?"), I think the noise level has become a bit too much there.
> Cornelius had proposed this rather daring idea:
>
> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2


Sounds great.  This should probably be done by picking a specific
technology in KDE, and adapting it and merging it to work in Qt.

A wonderful place to start would be kioslaves imho.  This is something
which has a real advantage, is relatively self-contained, and would
provide a big advantage.  Possibly it needs to be merged more with the
Qt API though.


Re: splitting up kdebase in git

2011-01-18 Thread John Tapsell
On 18 January 2011 21:34, Aaron J. Seigo  wrote:
> konsole, however, is a significant application in its own right that doesn't
> actually share code with the rest of the apps in there (besides Qt, kdelibs
> and runtime, of course ;). so it is getting its own repo.
>
> if there are any questions / concerns / thoughts on this, please provide your
> feedback now as we'd like to make the move as soon as possible once 4.6.0 is
> released.

apps/ksysguard could get its own repo as well.  It's completely
standalone, and (a few?) people want to compile ksysguardd (the
daemon) by itself.

John


Re: splitting up kdebase in git

2011-01-18 Thread John Tapsell
On 18 January 2011 22:05, Allen Winter  wrote:
> Having konsole, ksysguard, etc in their own git repo is fine.
> But they still will reside logically inside kdebase-apps
>
> For example on api.kde.org the EBN and LXR.

That's sounds great.

John


Re: splitting up kdebase in git

2011-01-18 Thread John Tapsell
On 18 January 2011 23:13, Aaron J. Seigo  wrote:
> the complication there is that krunner also relies on libksyguard, which lives
> in kdebase/workspace/libs/ksysguard. so we'd either end up with a really odd
> dependency in ksysguard on kde-workspace, or kde-workspace would end up
> depending on the ksysguard repository .. and then there's the matter of binary
> compatibility in the library due to that (a number of practical solutions
> there available to us, though).

Oh, what happened to the idea of making  kde-workspace-libs  a
standalone repo?  Wouldn't that make sense?


Re: splitting up kdebase in git

2011-01-18 Thread John Tapsell
On 18 January 2011 23:55, Aaron J. Seigo  wrote:
>> Oh, what happened to the idea of making  kde-workspace-libs  a
>> standalone repo?  Wouldn't that make sense?
>
> it could be done, but there was no use case for that. keeping the repos
> together lets us not worry so much about binary compat, too.

Ah.

Just leave ksysguard where it is then. :-)


Re: kdelibs, kdebase moving to Git this Saturday

2011-01-27 Thread John Tapsell
2011/1/27 Nicolás Alvarez :
> Please, help review the repositories before migration! Unlike KDE software,
> here we won't have point releases to fix bugs later :)


I have quite a few commits in kdebase-workspace with the commit message:

SVN_SILENT:
Do blahblah

and

GUI:
do blah blah


Since git places a high important on the very first line, could we
mangle these into  "SVN_SILENT: Do blahblah"  and "GUI: do blah blah"
 ?

So check if the first line contains only a keyword, and if so combine
with next line?

John


Re: Policy on git feature branches

2011-02-01 Thread John Tapsell
On 1 February 2011 09:21, Sebastian Trüg  wrote:
> Hi list,
>
> I have been working on an improvement for Nepomuk via git-svn for a
> while now and would now like to push it to kde-runtime.
> However, I would prefer to keep the commit history and backport to 4.6.
> Thus, I thought of pushing my feature branch into the kde-runtime
> repository and then merge it into master and 4.6. Is this an acceptable
> way to handle such a situation? Or should I merge locally only and then
> push both master and 4.6?

If you're not going to be working on this with other people, there's
no point making a remote branch.

And you don't want to be merging, you want to be cherry-picking.

John


Re: Merge or Cherry-Pick?

2011-02-01 Thread John Tapsell
> But how would a similar work flow except there are multiple fixes
> present in the local repo ? How would you push only a single fix in
> such case ?

git rebase -i origin   #Bring up a list of your changes.





git pull --rebase   #make sure we are up to date

git log  #copy the SHA of the commit you want to push up to

git push origin SHA:head   #paste the SHA that you just copied where I
wrote "SHA"


Does that make sense?  There are other ways to do it, but this way
avoids most of the common problems.

John


Re: Merge or Cherry-Pick?

2011-02-02 Thread John Tapsell
On 2 February 2011 07:27, Dawit A  wrote:
> Ahh... I see. It is push everything upto that commit, not just push
> that commit. Ouch! That is almost as much a hassle as the convoluted
> method I am following now. Do not commit anything that is not ready to
> be pushed into my own local branch. Use git stash to save the
> uncommited changes before doing the pull --rebase and apply the
> stashed changes after doing the push...

And then one day you do  "git checkout ."  by mistake and lose all
your local uncommitted changes that you just spent a week working on
..


Re: Merge or Cherry-Pick?

2011-02-02 Thread John Tapsell
On 2 February 2011 14:23, Parker Coates  wrote:
> On Wed, Feb 2, 2011 at 09:05, John Layt wrote:
>> On Wednesday 02 February 2011 13:43:04 Parker Coates wrote:
>>> My preferred workflow is to put all local commits intended for master
>>> in a single, local, long-lived "workmaster" branch instead of putting
>>> them in master directly. Since the changes are local, you can just
>>> keep rebasing it onto master every time master is updated.
>>>
>>> Then if you want to push a single commit from the work branch:
>>>     * pull master
>>>     * you interactively rebase the workmaster branch onto master to
>>> put the desired commit first
>>>     * merge the SHA you want to commit into master
>>>     * push master
>>>
>>> I find that by keeping my commits out of master itself allows me to
>>> update without worries, to commit high priority fixes without messing
>>> up my local work, and to commit early and often locally while still
>>> having the option to clean things up later with some rebasing.
>>>
>>> Personally, I found this ability to keep my local commit queue out of
>>> the way was the biggest advantage of switching to Git.
>>>
>>> Parker
>>
>> Personally, I think you should NEVER have commits in master, you should only
>> ever work in and push from branches, they're so cheap to do.  That way your
>> master is always a clean pure copy of the main repo to branch off.
>>
>> If I needed to extract a single commit out of a branch to push, rather than
>> merging it to master I'd create a new branch from master and cherry-pick the
>> commit to that, build and test it knowing it's clean, then push from there.
>> Then pull master and rebase the original branch on master again.
>
> Hmm. You're probably right. The majority of my Git experience has been
> with git-svn where it's pretty much mandatory to commit via master. In
> a pure Git environment, I guess it should be possible to keep master
> 100% clean.

It seems that I go against the grain, and always develop in master.

You already have "origin/master" as a pristine version of upstream
master, and you don't have to worry about it getting out of sync.

E.g:

git log   #find SHA1 of commit  I want to push upstream

git checkout origin/master  #we are now on an "unnamed" branch

git cherry-pick SHA  # still on an 'unnamed branch'

#compile, test, fix, etc.

git push origin HEAD:master

git checkout master

git pull --rebase   #rebase on top of remote, which now has our change

John


Re: git won't let me delete a branch?

2011-02-05 Thread John Tapsell
On 5 February 2011 20:03, Ben Cooksley  wrote:
> On Sun, Feb 6, 2011 at 8:58 AM, Thomas Lübking
>  wrote:
>> Hi,
>> i've "accidentally" pushed a "4.6" (NOT "KDE/4.6") branch to remote (sorry),
>> where it does oc. not belong...
>>
>> However "git push origin :4.6" fails by:
>>
>> remote: D refs/heads/4.6 kde-workspace luebking DENIED by fallthru
>> remote: error: hook declined to update refs/heads/4.6
>> To ssh://g...@git.kde.org/kde-workspace
>>   ! [remote rejected] 4.6 (hook declined)
>>
>> So, how do i remove this (pretty confusingly named) branch?
>
> Only repository admins are allowed to delete branches on git.kde.org.
> I have now deleted this branch.


The way that it works for the public Qt repository is that no one can
create or delete branches.  But anyone can clone the repository, and
then create/delete branches there as they want.

Shouldn't we have something similar?

John


Re: moving scratch repositories?

2011-02-05 Thread John Tapsell
Btw, since it wasn't obvious to me at the start, git branches can be
from completely different repositories, even completely unrelated
ones.  You can do  "git add remote"  to add new repositories.

Then you can use cherry-pick to move patches from one repository to
the other.  As long as the paths match up, git is fine with it.  They
don't need to have any common root or anything.

(If the paths don't match up, do the rewrite as Stephen said)

John


Re: git won't let me delete a branch?

2011-02-06 Thread John Tapsell
On 5 February 2011 20:39, Stefan Majewsky
 wrote:
> Don't we have this yet? I'm using exactly this approach for my work
> branches in libtagaro (cf. kde:libtagaro and
> kde:clones/libtagaro/majewsky/work). The only fear I'm having is that
> I'll once run into this 100-commits-per-push-operation limit.


Btw, you know about squashing commits right?

If you have a commit that you haven't pushed upstream, then a later
commit which fixes a problem in the first commit, then you should do
"git rebase -i origin"  and reorder the commits and make one commit as
to be squashed into the previous commit, so that you end up with a
single commit.

(You might already know, but I want to throw out tips for other people as well).

John


Future of KSysguard - removing remote monitoring

2011-03-08 Thread John Tapsell
Hi all,

  For the past 13 years or so, ksysguard has been in KDE under various
names.  Right from the beginning it was designed to monitor remote
systems as well as local ones.

  To monitor remote systems, it can connect to a remote machine via
rsh, ssh, etc, and communicate via a very simple plain text protocol.

  However over the years this design has slowly strangled future
development, and has scared off several contributors.  People have a
great idea and want to add it, then as I start to explain how they
need to implement it, their eyes get wider as they start to back away
slowly.

  So unless anyone can talk me out of it now, I am going to remove the
ability to monitor remote hosts entirely, and to use one of the many
excellent cross-platform debugged libraries that already exist to
gather system information.

John


Re: Future of KSysguard - removing remote monitoring

2011-03-09 Thread John Tapsell
Thanks for the feedback - this is why I put out such emails before I
make any changes.  It's good to know that people actually use this app
- sometimes it's hard to know if anyone actually uses it.

I'll hold off on any rash changes for now.

Thanks!

John


Re: Future of KSysguard - removing remote monitoring

2011-03-10 Thread John Tapsell
On 10 March 2011 14:43, Cristian Tibirna  wrote:
> On March 8, 2011, John Tapsell wrote:
>> Hi all,
>>
>>   For the past 13 years or so, ksysguard has been in KDE under various
>> names.  Right from the beginning it was designed to monitor remote
>> systems as well as local ones.
>
> John, thanks a lot for taking care of ksysguard. I consider it one of the best
> applications of the KDE basic workspace. I push it energetically on all sys-
> admins I find (and usually they're easily convinced).
>
> I believe the most important feature of ksysguard is its remote capability. I
> must acknowledge that I know very little of the mechanics of this feature (yet
> I know it is developed in-house, since at the time (long ago...), Chris
> Schlaeger didn't really have much choice in terms of monitoring libraries).
>
> I dare to ask you consider to not remove this feature. Perhaps your
> observation is rather an occasion to look at some redesign (and reuse of
> better (?) technologies in remote monitoring).


Thanks - you guys have already changed my mind :-)

John


Re: Future of KSysguard - removing remote monitoring

2011-03-10 Thread John Tapsell
On 9 March 2011 16:05, Gary Greene  wrote:
> On 9 Mar 2011, at 7:54 AM, John Tapsell wrote:
>> Thanks for the feedback - this is why I put out such emails before I
>> make any changes.  It's good to know that people actually use this app
>> - sometimes it's hard to know if anyone actually uses it.
>>
>> I'll hold off on any rash changes for now.
>>
>> Thanks!
>>
>> John
>>
>
> Has ksysguard (at least the front-end) been ported to Mac OS X? This would 
> save me a lot of time in having to invest time and effort in creating a 
> web-monitoring system for a few sites I do admin stuff for If not, what 
> is preventing it from working on that platform (if any), and would you 
> welcome any help for getting it completed?

It hasn't been ported afaik, but it works on BSD and solaris etc, so I
don't think porting it would be a huge deal.  You could probably just
try compiling it and sending me any fixes that are needed.

John


How to know if I'm showing a tooltip?

2011-03-18 Thread John Tapsell
Hi all,

  When the user hovers over an item, it shows a tooltip.  I update
that tooltip once a second using the following code:

if(QToolTip::isVisible()) {
QWidget *w = d->mUi->treeView->viewport();
if(w->geometry().contains(d->mUi->treeView->mapFromGlobal(
QCursor::pos() ))) {
QHelpEvent event(QEvent::ToolTip, w->mapFromGlobal(
QCursor::pos() ), QCursor::pos());
qApp->notify(w, &event);
}
}

This works, but the trouble is is that the tooltip could be visible
due to a dialog window.  So if I open a dialog box, then hover over an
item in that dialog box, it shows the correct tooltip for a moment,
then changes to the tooltip for the main window underneath, due to
that code I pasted above.

I've tried  && window()->isActiveWindow()  which partially solves the
problem, but it's possible to have a dialog box on top, but have the
main window have the focus..

Any ideas?

JohnFlux


Re: How to know if I'm showing a tooltip?

2011-03-18 Thread John Tapsell
On 18 March 2011 11:24, John Tapsell  wrote:
> I've tried  && window()->isActiveWindow()  which partially solves the
> problem, but it's possible to have a dialog box on top, but have the
> main window have the focus..


I figured it out - I just need:

if (QToolTip::isVisible() && qApp->topLevelAt(QCursor::pos())
== window()) {

JohnFlux


Re: 4.6 branches created in git again

2011-03-20 Thread John Tapsell
Why do we let people create branches on the main git server anyway?


Re: 4.6 branches created in git again

2011-03-20 Thread John Tapsell
On 20 March 2011 15:01, Albert Astals Cid  wrote:
> A Diumenge, 20 de març de 2011, John Tapsell va escriure:
>> Why do we let people create branches on the main git server anyway?
>
> How are you supposed to work on a feature-branch otherwise?

By having it in your own git repository.  This is how Qt does it.
Anyone can clone the Qt repository on the server and create branches
in their own clone.
For example, here is mine:  http://qt.gitorious.org/~johnflux- and
other people can (and do) work on it.

John


KLocalizedString regression

2011-03-25 Thread John Tapsell
Hi all,

 ki18ncp("Units", "%1 second", "%1 seconds").subs(1.1, 0, 'f', 1).toString()

used to work  (return "1.1 seconds")  but now it returns ("1.1
seconds(I18N_PLURAL_ARGUMENT_MISSING)")  which screws up my graphing
widget.

This causes my unit tests to fail.

Can someone fix this pretty please?  I can't work around this.

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 12:45, Chusslove Illich  wrote:
>> [: John Tapsel :]
>>   ki18ncp("Units", "%1 second", "%1 seconds").subs(1.1, 0, 'f', 1).toString()
>>
>> used to work (return "1.1 seconds") but now it returns ("1.1
>> seconds(I18N_PLURAL_ARGUMENT_MISSING)") which screws up my graphing
>> widget.
>
> This is the way it (should have) always worked. The plural call expects to
> get an integer, and if does not, it shows this warning (in debug build, not
> in release build).

That's not good :-(

If the number is small, I want to show   "2 seconds"   but if it's
large I want like "2.2e4" seconds.

You're saying that my API needs to require the user to now pass *two*
strings for that?

> On the language level, plural declination kicks in only on integer values,
> while real values always get plural form. This seems to hold for all
> languages currently known in KDE. In English, all of "1.0 seconds",
> "1.1 seconds", "1.3 seconds", and "2.3 seconds", are (?) both correct and
> expected forms, as opposed to "1 second" and "2 seconds".


And that's fine.  So do that.  But don't stick a big warning there!

If I specify a precision of 0, then it should be   "1 second".  If the
precision is "1" then "1.0 seconds" is fine.

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 13:19, Chusslove Illich  wrote:
>> [: John Tapsell :]
>> If the number is small, I want to show "2 seconds" but if it's large I
>> want like "2.2e4" seconds.
>>
>> You're saying that my API needs to require the user to now pass *two*
>> strings for that?
>
> Well, yes. Two grammar-wise different text fragments (enumerable vs.
> measurable quantities) are being used in alternation, so each should be
> represented by its own string. The author of KUnitConversion wanted the same
> feature, so there too we ended up defining two strings, e.g:
>
>      setDefaultUnit(UP(Meter, 1,
>        ...
>        ki18nc("amount in units (real)", "%1 meters"),
>        ki18ncp("amount in units (integer)", "%1 meter", "%1 meters")
>      ));

Except that in my case, I'm forcing this on the users of my API.  Just
to get around this!

Can't you see how crazy this is?

> In my opinion, however, this alternation is bad style-wise. The display
> should use either the measurable form throughout (2.0 seconds; 2.2e4
> seconds), or the enumerable form throughout (2 seconds; 6 hours 6 minutes).

But what if I want to allow both?  This is for labelling the axis of a
graph.  I now have to have an API and forces the users to give the
same string twice.


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 13:59, John Tapsell  wrote:
> On 25 March 2011 13:19, Chusslove Illich  wrote:
>>> [: John Tapsell :]
>>> If the number is small, I want to show "2 seconds" but if it's large I
>>> want like "2.2e4" seconds.
>>>
>>> You're saying that my API needs to require the user to now pass *two*
>>> strings for that?
>>
>> Well, yes. Two grammar-wise different text fragments (enumerable vs.
>> measurable quantities) are being used in alternation, so each should be
>> represented by its own string. The author of KUnitConversion wanted the same
>> feature, so there too we ended up defining two strings, e.g:
>>
>>      setDefaultUnit(UP(Meter, 1,
>>        ...
>>        ki18nc("amount in units (real)", "%1 meters"),
>>        ki18ncp("amount in units (integer)", "%1 meter", "%1 meters")
>>      ));
>
> Except that in my case, I'm forcing this on the users of my API.  Just
> to get around this!
>
> Can't you see how crazy this is?
>
>> In my opinion, however, this alternation is bad style-wise. The display
>> should use either the measurable form throughout (2.0 seconds; 2.2e4
>> seconds), or the enumerable form throughout (2 seconds; 6 hours 6 minutes).
>
> But what if I want to allow both?  This is for labelling the axis of a
> graph.  I now have to have an API and forces the users to give the
> same string twice.


Chusslove, I just had an idea - so okay, if I'm forced to work around
this feature, could I do:

string.remove("(I18N_PLURAL_ARGUMENT_MISSING)");

This string won't change, and isn't translated right?

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 14:20, Thiago Macieira  wrote:
> Em sexta-feira, 25 de março de 2011, às 13:59:11, John Tapsell escreveu:
>> > Well, yes. Two grammar-wise different text fragments (enumerable vs.
>> > measurable quantities) are being used in alternation, so each should be
>> > represented by its own string. The author of KUnitConversion wanted the
>> > same feature, so there too we ended up defining two strings, e.g:
>> >
>> >      setDefaultUnit(UP(Meter, 1,
>> >        ...
>> >        ki18nc("amount in units (real)", "%1 meters"),
>> >        ki18ncp("amount in units (integer)", "%1 meter", "%1 meters")
>> >      ));
>>
>> Except that in my case, I'm forcing this on the users of my API.  Just
>> to get around this!
>>
>> Can't you see how crazy this is?
>
> No. You haven't said anything about your API yet.
>
> Maybe the problem is in the API. But we don't know, because you haven't
> included a link to what API you're talking about.

I have a widget, KSignalPlotter, which plots data points.

The usage is:

KSignalPlotter plotter;
plotter.setUnit( ki18ncp("Units", "%1 second", "%1 seconds") );
plotter.addBeam(Qt::red);
plotter.addSample( QList() << 2 );

For example.

The axis will then be labelled using the "unit" string.  The precision
will be calculated automatically.

> Huh? Why do you want to show "1.0 seconds" in the axis? Shouldn't you have
> "1.0" in the axis and then "seconds" in the axis label?

Because typically we have a lot more horizontal space than vertical
space.  Adding room for axis labels would take up valuable vertical
space.

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 15:06, Thiago Macieira  wrote:
> Em sexta-feira, 25 de março de 2011, às 14:39:22, John Tapsell escreveu:
>> I have a widget, KSignalPlotter, which plots data points.
>>
>> The usage is:
>>
>> KSignalPlotter plotter;
>> plotter.setUnit( ki18ncp("Units", "%1 second", "%1 seconds") );
>> plotter.addBeam(Qt::red);
>> plotter.addSample( QList() << 2 );
>>
>> For example.
>>
>> The axis will then be labelled using the "unit" string.  The precision
>> will be calculated automatically.
>
> So you might have a graph showing 1, 2, and 3 where the unit is "2.2e4
> seconds" ?

The graph would show  "1 second"  "2 seconds" "3 seconds"   on the
axis in this case.

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 21:42, Chusslove Illich  wrote:
>> [: John Tapsell :]
>> Except that in my case, I'm forcing this on the users of my API. Just to
>> get around this!
>>
>> Can't you see how crazy this is?
>
> An integer is mandatory to decide the plural form, a float cannot be used,
> due to the following. Suppose there are m plural forms for a given language.
> The plural call pushes the integer through a formula, defined by that
> language (by each PO file to be precise), which maps it to 0 through m - 1.
> If the plural call would get a float instead, how should it decide which of
> the m forms to map to? For example, in my language forms are 0 through 3,
> and the correct one for a floating value is 2 -- not 0, 1, or 3.
>
> On the implementation level, what happens now when you do not supply an
> integer, is that non-plural call is simply passed down to non-plural
> gettext() from libc. It is a fluke that for English it silently returns the
> plural, and not the singular string. For all I know, if the libc were built
> in develop/debug mode (I use distribution package), it could do something
> else.
>
> Therefore two independent KLocalizedString parameters are indeed necessary
> for the API, if you want to keep the integer/real alternation. Since it is
> about graph plotting, I suggest that you make the API such that the real-
> value string is mandatory, and the integer-value string optional. I.e. let
> the client choose if he wants alternation or not.

Thank you very much your explanation - it makes a lot more sense to me now :-)

> Furthermore, I would suggest that the axis tick labels be pure numbers, and
> the axis name and unit shown separate in one place, e.g:
>
>  -->
>  0     1     2     3     4     5     6
>              time [seconds]

As an published engineer myself, I fully understand.  But there's a
few practical problems - we do not have much vertical space, for
example.  Putting on such an axis would pretty much halve the height
available for the graph itself.

If you were thinking of this for the vertical axis, then you are
either asking for vertical text, which is evil, or a huge amount of
wasted on the left hand side.

John


Re: systemd and KDE (was: Re: kdeinit)

2011-09-14 Thread John Tapsell
Regarding integration - for a long time I've been interested in adding
support to System Activity (ctrl+esc thingy).  In Windows, the task
manager has a tab for both processes and for services, and you can
switch between the two.  So you can right click on a process and jump
to its service, and vice versa.  This integration makes a lot of sense
since its often better to stop the service than to just kill the
process.

I've been somewhat waiting for the fight between upstart and systemd
to be resolved, and also it would be good to have the following DBUS
calls available to non-root users:

1) Return a list of currently running / stopped / runnable / etc  services
2) Provide user-friendly information about each service.  (Short
description that I can show to the user)
3) Provide a list of PIDs for a given service
4) Return the service for a given PID

Can these calls be added if necessary please?

JohnFlux


Re: systemd user session units for KDE

2012-06-24 Thread John Tapsell
On 24 June 2012 09:05, Thiago Macieira  wrote:
> Hello
>
> One of my colleagues at Intel has begun working on a project to have systemd
> launch and manage the user session. He's asking for help in getting KDE
> supported, since it's not his area of expertise.
>
> Is there anyone interested in helping him?

Would there be any value in having System Activity (ctrl+esc thing)
understand systemd ?

It has been a dream of mine to end up with a task manager like
Windows, where you can shut down services nicely as well as kill the
processes.

JohnFlux


Re: Review Request: ksysguard - Add rowspan/colspan support for displays

2013-01-04 Thread John Tapsell
Hi,
  I'm the maintainer.  The review gets my approval, but I'm a bit busy.

  Can someone else apply this please?

Thank you very much,

John

On 4 January 2013 19:44, Arnavion  wrote:

> Hi,
> I don't see this review request e-mail on the mailman archives, so I'm not
> sure it ever made it to the mailing list. Apologies if it did.
>  I did get an e-mail that the message "is being held until the list
> moderator can review it for approval", but I didn't receive any follow-up
> e-mails about that.
>  Arnav Singh
>
>
>
> On Thu, Dec 27, 2012 at 7:50 PM, Arnav Singh  wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> http://git.reviewboard.kde.org/r/107970/
>>   Review request for kde-workspace.
>> By Arnav Singh.
>> Description
>>
>> I've added support for sensor displays in KSysGuard to have row spans and 
>> column spans.
>>
>> Apart from adding rowSpan and columnSpan arguments to the method signatures, 
>> I've also removed the internal list (WorkSheet::mDisplayList) used to 
>> contain all the sensor displays. This list used to be used to derived the 
>> row and column of the displays based on their index in the list. Since I now 
>> need to maintain rowSpan and columnSpan information as well, I just removed 
>> the list entirely and get all my data from mGridLayout. As a result, another 
>> change in the method signatures is the replacement of the "index" parameter 
>> with "row" and "column" parameters.
>>
>> An extra advantage of doing it this way is that widgets don't shift around 
>> when resizing the grid. Another advantage is that blank spaces between the 
>> widgets are now possible. Not to mention, not maintaining the layout 
>> information outside of the actual layout component (mGridLayout) seems a 
>> clearer design to me.
>>
>>   Testing
>>
>> Works on 4.9.4
>>
>>   *Bugs: * 311925 
>> Diffs
>>
>>- ksysguard/gui/WorkSheet.h (9f4806d)
>>- ksysguard/gui/WorkSheet.cpp (b20f077)
>>
>> View Diff 
>> Screenshots
>> [image: Example] 
>>
>
>


Re: Review Request: ksysguard - Add rowspan/colspan support for displays

2013-01-05 Thread John Tapsell

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

Ship it!


Ship It!

- John Tapsell


On Dec. 28, 2012, 3:50 a.m., Arnav Singh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107970/
> ---
> 
> (Updated Dec. 28, 2012, 3:50 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Description
> ---
> 
> I've added support for sensor displays in KSysGuard to have row spans and 
> column spans.
> 
> Apart from adding rowSpan and columnSpan arguments to the method signatures, 
> I've also removed the internal list (WorkSheet::mDisplayList) used to contain 
> all the sensor displays. This list used to be used to derived the row and 
> column of the displays based on their index in the list. Since I now need to 
> maintain rowSpan and columnSpan information as well, I just removed the list 
> entirely and get all my data from mGridLayout. As a result, another change in 
> the method signatures is the replacement of the "index" parameter with "row" 
> and "column" parameters.
> 
> An extra advantage of doing it this way is that widgets don't shift around 
> when resizing the grid. Another advantage is that blank spaces between the 
> widgets are now possible. Not to mention, not maintaining the layout 
> information outside of the actual layout component (mGridLayout) seems a 
> clearer design to me.
> 
> 
> This addresses bug 311925.
> http://bugs.kde.org/show_bug.cgi?id=311925
> 
> 
> Diffs
> -
> 
>   ksysguard/gui/WorkSheet.h 9f4806d 
>   ksysguard/gui/WorkSheet.cpp b20f077 
> 
> Diff: http://git.reviewboard.kde.org/r/107970/diff/
> 
> 
> Testing
> ---
> 
> Works on 4.9.4
> 
> 
> Screenshots
> ---
> 
> Example
>   http://git.reviewboard.kde.org/r/107970/s/936/
> 
> 
> Thanks,
> 
> Arnav Singh
> 
>