Nabble - kde-quality

Re: Introducing me to the work

2009-12-19T08:58:34Z

On Saturday 19 December 2009 09:59:44 lnas90 lnas90 wrote:
> Well folks my name is Lucas Nunes, also known as lnas90 (lowercase L not I
> confuse people), I live in Brazil at Feira de Santana in Bahia state.

> Please if you have any task that can be really useful, let me know.

Well there's plenty to do in the KDE community if you want to help, trust me.
;)

The "official" page detailing how to get involved is at
http://www.kde.org/getinvolved/ (Sadly, this page is itself out of date in
many ways, with entries from 2004 and broken links :( ) Perhaps fixing the
"Get Involved" page should be the first thing we do! ;)

A more up to date page is the "How to Contribute" page on the KDE technical
wiki, TechBase. It even is partially translated to pt_BR
(http://techbase.kde.org/Contribute_(pt_BR) )

The big conclusion is that we could always use help with bug triaging (trying
to see if a bug is reproduceable or if it only exists on the bug reporter's
computer, also merging duplicate bug reports into a single existing one)

The pt_BR translation team might be able to use your help with translation
(although maybe not, maybe they have no work to do ;)

You could join a promotion team (see the kde-promo mailing list) and help
organize KDE conferences in the South Americas (and get to meet and work with
many fun people in the process)

So hopefully this helps you out.

Regards,
- Michael Pyne

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

signature.asc (853 bytes) Download Attachment

Introducing me to the work

2009-12-19T06:59:44Z

Well folks my name is Lucas Nunes, also known as lnas90 (lowercase L not I confuse people), I live in Brazil at Feira de Santana in Bahia state.
I have 19 years and using Linux is already about 5 years but have always been user, never liked programming, though perhaps find interesting.
I've written a book in Portuguese on Linux for beginners called Linux without Mystery, published in 2006.

As I said already I'm not a programmer and have not mastered the English language (I'm currently using the google translator to send this email), but I wanted to help the KDE, as I admire the work done here.
Please if you have any task that can be really useful, let me know.

Hugs

--
Deus te abençoe

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: help me for contributing

2009-12-07T20:11:15Z

Unfortunately, the whole KDE is done in C++, not C.
but if you Really wanna help, I can help you with mentoring.
do you have time and are willing to be a KDE hacker?

Tomaz,

Em Segunda-feira 07 Dezembro 2009, às 13:40:36, Aditya C.S escreveu:
> I am Aditya.cs from bangalore.I am doing my first year engineering.I have
> knowledge about C program.I want to contibute for the kde project.What
> junior job can I take with a knowledge of C
>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

help me for contributing

2009-12-07T08:40:36Z

I am Aditya.cs from bangalore.I am doing my first year engineering.I have knowledge about C program.I want to contibute for the kde project.What junior job can I take with a knowledge of C

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Suggestion: shell on window's back

2009-12-03T08:43:36Z

On Thursday 19 Nov 2009 23:37:16 Marvin Lampe wrote:
> Well sure, but I think of a whole functional shell on the back which is
> also closed when the window is closed.
> It shall not replace a kind of logfile but makes it handier to debug.
> Furthermore it's some kind of "cool" just
> to flip a window and see what's going on with it.
> But a nice feature would also be a "split" button on the backside shell
> which allows to create a similar one without
> a "frontside" and without disappearing when the program is closed.

I agree - that does sound kind of cool :-)
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Suggestion: shell on window's back

2009-12-03T08:11:57Z

On Thursday 03 Dec 2009 15:45:41 Alvaro Aguilera wrote:
> how about creating something like syslog for kde? when an application finds
> a problem, it write some output to /var/log/kde or similar.

I thought that things generally got output into ~/.xsession-errors.

Or are you thinking of something else?

Pete.
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Suggestion: shell on window's back

2009-12-03T07:45:41Z

how about creating something like syslog for kde? when an application finds a problem, it write some output to /var/log/kde or similar.

On Thu, Dec 3, 2009 at 4:37 PM, Iñaki Baz Castillo <ibc@...> wrote:

El Jueves, 19 de Noviembre de 2009, Marvin Lampe escribió:
> Everyone will surely know a situation like that: You're running a program
> for a while and suddenly something unexpected happens. The application
> crashes, freezes or gets insufferable slow.
> You forgot to start the program inside a console before, and now can't get
> any information for debugging. The conditions which led to the crash
> aren't reproducible (you don't remember what you did since
> the launch of the program or you just have no idea what the hell caused
> the crash) and you can't solve the problem now. The only thing you can do
> is to wait until the problem occurs again and then hopefully
> have started the application inside a shell...
>
> I think it would be nice to have a feature for displaying the stdout of an
> application in a handy way without having to start it in a separate
> console.
> Every time a new application gets launched, there should be a shell
> starting with it. The main problem with this is that the shell would be
> quite annoying until it gets useful. It consumes place in
> your window list and is floating around your desktop. So my idea here is
> to put that console on the process' window back, and allow the user to
> flip the window by a quadruple click,
> pulling the lower right corner to the upper right or something like that,
> perhaps with a nice compositing effect :-).
> The possible problem of several child windows by one single application
> (for example in The Gimp) could be solved by displaying the stdout of the
> root process on the back of every child window.
>
> I would appreciate you to comment on this.

A great idea ;)

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Suggestion: shell on window's back

2009-12-03T07:37:33Z

El Jueves, 19 de Noviembre de 2009, Marvin Lampe escribió:

> Everyone will surely know a situation like that: You're running a program
> for a while and suddenly something unexpected happens. The application
> crashes, freezes or gets insufferable slow.
> You forgot to start the program inside a console before, and now can't get
> any information for debugging. The conditions which led to the crash
> aren't reproducible (you don't remember what you did since
> the launch of the program or you just have no idea what the hell caused
> the crash) and you can't solve the problem now. The only thing you can do
> is to wait until the problem occurs again and then hopefully
> have started the application inside a shell...
>
> I think it would be nice to have a feature for displaying the stdout of an
> application in a handy way without having to start it in a separate
> console.
> Every time a new application gets launched, there should be a shell
> starting with it. The main problem with this is that the shell would be
> quite annoying until it gets useful. It consumes place in
> your window list and is floating around your desktop. So my idea here is
> to put that console on the process' window back, and allow the user to
> flip the window by a quadruple click,
> pulling the lower right corner to the upper right or something like that,
> perhaps with a nice compositing effect :-).
> The possible problem of several child windows by one single application
> (for example in The Gimp) could be solved by displaying the stdout of the
> root process on the back of every child window.
>
> I would appreciate you to comment on this.

A great idea ;)

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Suggestion: shell on window's back

2009-11-19T15:37:16Z

Am 03.12.2009, 17:11 Uhr, schrieb Peter Lewis <prlewis@...>:

> On Thursday 03 Dec 2009 15:45:41 Alvaro Aguilera wrote:
>> how about creating something like syslog for kde? when an application
>> finds
>> a problem, it write some output to /var/log/kde or similar.
>
> I thought that things generally got output into ~/.xsession-errors.
>
> Or are you thinking of something else?
>
> Pete.
> _______________________________________________
> kde-quality mailing list
> kde-quality@...
> https://mail.kde.org/mailman/listinfo/kde-quality

Well sure, but I think of a whole functional shell on the back which is
also closed when the window is closed.
It shall not replace a kind of logfile but makes it handier to debug.
Furthermore it's some kind of "cool" just
to flip a window and see what's going on with it.
But a nice feature would also be a "split" button on the backside shell
which allows to create a similar one without
a "frontside" and without disappearing when the program is closed.

Marvin Lampe
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Suggestion: shell on window's back

2009-11-19T14:27:24Z

Everyone will surely know a situation like that: You're running a program
for a while and suddenly something unexpected happens. The application
crashes, freezes or gets insufferable slow.
You forgot to start the program inside a console before, and now can't get
any information for debugging. The conditions which led to the crash
aren't reproducible (you don't remember what you did since
the launch of the program or you just have no idea what the hell caused
the crash) and you can't solve the problem now. The only thing you can do
is to wait until the problem occurs again and then hopefully
have started the application inside a shell...

I think it would be nice to have a feature for displaying the stdout of an
application in a handy way without having to start it in a separate
console.
Every time a new application gets launched, there should be a shell
starting with it. The main problem with this is that the shell would be
quite annoying until it gets useful. It consumes place in
your window list and is floating around your desktop. So my idea here is
to put that console on the process' window back, and allow the user to
flip the window by a quadruple click,
pulling the lower right corner to the upper right or something like that,
perhaps with a nice compositing effect :-).
The possible problem of several child windows by one single application
(for example in The Gimp) could be solved by displaying the stdout of the
root process on the back of every child window.

I would appreciate you to comment on this.

Thanks,
Marvin Lampe

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Cloning Amarok from Gitorious

2009-11-19T07:08:22Z

Heya,

Ade had asked for instructions for cloning Amarok from Gitorious. Here goes:

git clone git://gitorious.org/amarok/amarok.git

Thanks :)

--
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: userbase

2009-11-01T13:31:55Z

On Sun, Nov 1, 2009 at 7:28 PM, <genericmaillists@...> wrote:
> I found a mistake in the userbase information. I tried to edit, which
> I was able to do but there was no way to save the changes.
Wasn't there a "Save Page" button after the text box?
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

userbase

2009-11-01T13:28:25Z

I found a mistake in the userbase information. I tried to edit, which
I was able to do but there was no way to save the changes. The link to
the page is:
http://userbase.kde.org/Plasma/FAQ/4.3
The information that needs correcting is:

My panel is gone, how do I get it back?

kquitapp plasma-desktop; rm
$KDEHOME/share/config/plasma-desktop-appletsrc; plasma-desktop

This deletes your plasma settings, so you'll get the default
configuration back. If running *all the* 3 commands at once doesn't
work, try typing them in manually and wait a few seconds before
running the next command.

In the above section, one of the sentences should read this way:

If running *all* 3 commands at once doesn't work, try typing them in
manually and wait a few seconds before running the next command.

or this way:

If running *the* 3 commands at once doesn't work, try typing them in
manually and wait a few seconds before running the next command.

This * is used only to focus where the problem is located.
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: KDE Quality webmaster mail bouncing

2009-10-21T06:39:06Z

On Sun, Jan 7, 2007 at 2:32 PM, Adriaan de Groot <groot@...> wrote:

> On Sunday 07 January 2007 19:02, Will Entriken wrote:
>> I am trying to contact the Webmaster of quality.kde.org (via the link
>> on the bottom of every quality page), but email to
>> carloswoelz@... is bouncing. Is this the case for anyone
>> else? Is there another email address to put up there?
>
> As far as I know Carlos has vanished from the face of the earth. It's
> unfortunate, he was very passionate about KDE quality, but ran into some
> personal time issues that dragged him away from KDE.
>
>> Anyway, my business is that I am maintaining
>> http://kde.org/getinvolved/. I am trying to consolidate information
>> into this page from all over KDE and I would like to work with whoever
>> maintains http://quality.kde.org/develop/howto/howtohack.php in an
>> effort to avoid duplication and increase quality and timeliness of
>> information.
>
> SVN log for any information. I'd really like to kill the quality.k.o site and
> list myself.

The quality site has been unchanged in 2 years:
http://websvn.kde.org/trunk/quality/website/

Can we safely remove this now?
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Kde-Quality homepage giving a lot of 404 errors.

2009-10-17T16:29:30Z

Hello,
I am getting lots of 404s on the kde quality team homepage.[1]

Under the section 'KDE Quality Team Modules and Applications Pages'
almost all the links are pointing to pages Which do not exist.

* http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+PIM
* http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+Koffice
* http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+Edu
* http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+Multimedia

And The following domain is parked.
* http://kde-artists.org/

Whom do I contact to get this fixed? Or how do I fix it myself ?

TIA

[1]http://quality.kde.org/
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: About KDE bug tracker

2009-09-20T15:32:04Z

El Domingo, 20 de Septiembre de 2009, Josh Berry escribió:
> Well, all of the gripes you have mentioned so far can be totally
> removed by changing a few preferences. :)
>
> The defaults are the way they are because they work well for the
> majority of the heavy users of the bug-tracking system, so unless a
> lot of the developers start complaining, I wouldn't expect them to
> change.

Thanks, I didn0t realize that I can customize it (which is great for me).

Thanks a lot.

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: About KDE bug tracker

2009-09-20T11:03:18Z

On Sep 20, 2009, at 3:13 , Iñaki Baz Castillo wrote:

> El Domingo, 20 de Septiembre de 2009, Juan Carlos Torres escribió:
>> On Sun, Sep 20, 2009 at 12:25 AM, Iñaki Baz Castillo
>> <ibc@...> wrote:
[snip]

>>> - Searching for a specific bug is a pain as the involved component
>>> (ie:
>>> kmail,
>>> kopete, plasma...) is not a column when the bugs are shown.
>>
>> Not sure what you mean.
>
> In the above page ("Show all open reports that I reported") there is
> list of
> bugs/wishes reported by me. It shows the following columns. This is
> a real
> entry of the list:

This is because most of the time, when you are dealing with a list of
bugs, you care only about a specific application. In the common use
case, it doesn't make sense to view the product/component.

The people typically viewing lists of bugs are developers or QA people
who are working on a specific application, and want to walk through
the list of bugs for that application. It would be a waste of space
for the KMail developer to see that all the bugs in his list are kmail
bugs -- he knows that already!

End users (bug reporters) typically do not deal with lists -- they
file specific bugs, and then return to comment on those bugs (e.g.
with more information) when they get email saying a bug has been
updated.

In any case, this is configurable. When you are viewing a bug list,
scroll to the bottom and click the "Change Columns" link.

[snip]
> Also, go to "Show all open reports that I reported" and filter all
> your bugs
> related to Kmail, easy? not at all, you must read all the summaries
> (perhaps
> some of them says "deleting a folder fails", how do you know if that
> bug is
> related to Kmail, Konqueror, Dolphin...?)

You should use the Search tool to do this.

What's more, if you find yourself doing a search more than a few
times, it's probably a good idea to save the search, so you can repeat
it again by clicking on a link.

>>> - After posting a comment in a bug, that bug dissapears and the
>>> next one
>>> appears... ¿?
>>
>> Again, not sure what you mean. What "next one"? I just commented on
>> a bug
>> right now and it didn't go to a "next one".
>
> Right now I've added a comment in this hateful bug 196949 reported
> by me:
>
> https://bugs.kde.org/show_bug.cgi?id=196949
>
> after pressing "Commit" the new URL is:
>
> https://bugs.kde.org/process_bug.cgi (which says nothing of course)
>
> and the new page shows:
>
> "The next bug in your list is bug 202512:"
> (followed by the entire description of bug 202512)
>
> This is: I'm redirected to the next bug in my list, why??

Because in most cases once someone is finished dealing with a bug,
they leave a comment on it and move on to the next bug in the list.
Bugzilla automates this for you because again, the people most often
dealing with lists are the developers.

If, however, you don't have a current list (e.g. you clicked on a link
in a bug email to reply to that particular bug), Bugzilla will stay on
the current bug.

This is also configurable. Click the "Edit my Preferences" link in
the left sidebar (under "My Account"), and change the "After changing
a bug" setting to "Show the updated bug".

>> And I the only who doesn't feel confortable with current bug tracker?
>>
>>> Is there any aim to change/improve it?
>>
>> KDE is using Bugzilla for it's bug tracker. It is not a homebrew
>> application. So whatever limitations you're bumping into, almost
>> all users
>> of Bugzilla also experience. There is always an ongoing communication
>> between KDE and Bugzilla on how it can be improved. You can find
>> out more
>> about them at http://www.bugzilla.org/
>
> I use lots of bug trackers in different projects, also Bugzilla. I
> expect that
> it is customizable and the configuration for KDE's bug tracker is just
> "wrong". In any other project's bugtracker I feel more confortable
> (but in
> KDE's bugtracker sometimes I look for my own reported bugs in Google
> as it's
> faster than searching in "Show all open reports that I reported").
> Also, I'm not the only person complaining about it, I've read
> similar opinions
> in some forums and lists.

Well, all of the gripes you have mentioned so far can be totally
removed by changing a few preferences. :)

The defaults are the way they are because they work well for the
majority of the heavy users of the bug-tracking system, so unless a
lot of the developers start complaining, I wouldn't expect them to
change.

-- Josh

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: About KDE bug tracker

2009-09-20T03:13:45Z

El Domingo, 20 de Septiembre de 2009, Juan Carlos Torres escribió:
> On Sun, Sep 20, 2009 at 12:25 AM, Iñaki Baz Castillo <ibc@...> wrote:
> > Hi, in my opinion KDE's bug tracker is the worst I've ever seen:
> >
> > - I *never* find my reported bugs.
>
> Once logged in, in the front page, there is a "Managing you Account"
> section where you have "Show all open reports that I reported".

Yes.

> > - Searching for a specific bug is a pain as the involved component (ie:
> > kmail,
> > kopete, plasma...) is not a column when the bugs are shown.
>
> Not sure what you mean.

In the above page ("Show all open reports that I reported") there is list of
bugs/wishes reported by me. It shows the following columns. This is a real
entry of the list:

ID => 129928
Sev => nor
Pri => NOR
OS => Linu
Assignee => (as zander@...)
Status => UNCO
Resolution => <empty>
Summary => Changing the grammatical corrector language in
"Tools" menu doesn't work

Just by reading these column values, please tell me which KDE
component/application we are speaking about.
No idea, right? You must read the entire bug to realize of it.

When you open the bug you see "Product: kword". Why doesn't "Product" appear
in the previous list?? (as in *any* bug tracker in the world).

Also, go to "Show all open reports that I reported" and filter all your bugs
related to Kmail, easy? not at all, you must read all the summaries (perhaps
some of them says "deleting a folder fails", how do you know if that bug is
related to Kmail, Konqueror, Dolphin...?)

> > - After posting a comment in a bug, that bug dissapears and the next one
> > appears... ¿?
>
> Again, not sure what you mean. What "next one"? I just commented on a bug
> right now and it didn't go to a "next one".

Right now I've added a comment in this hateful bug 196949 reported by me:

https://bugs.kde.org/show_bug.cgi?id=196949

after pressing "Commit" the new URL is:

https://bugs.kde.org/process_bug.cgi (which says nothing of course)

and the new page shows:

"The next bug in your list is bug 202512:"
(followed by the entire description of bug 202512)

This is: I'm redirected to the next bug in my list, why??

> And I the only who doesn't feel confortable with current bug tracker?
>
> > Is there any aim to change/improve it?
>
> KDE is using Bugzilla for it's bug tracker. It is not a homebrew
> application. So whatever limitations you're bumping into, almost all users
> of Bugzilla also experience. There is always an ongoing communication
> between KDE and Bugzilla on how it can be improved. You can find out more
> about them at http://www.bugzilla.org/

I use lots of bug trackers in different projects, also Bugzilla. I expect that
it is customizable and the configuration for KDE's bug tracker is just
"wrong". In any other project's bugtracker I feel more confortable (but in
KDE's bugtracker sometimes I look for my own reported bugs in Google as it's
faster than searching in "Show all open reports that I reported").
Also, I'm not the only person complaining about it, I've read similar opinions
in some forums and lists.

Regards.

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: About KDE bug tracker

2009-09-19T17:48:18Z

On Sun, Sep 20, 2009 at 12:25 AM, Iñaki Baz Castillo <ibc@...> wrote:

Hi, in my opinion KDE's bug tracker is the worst I've ever seen:

- I *never* find my reported bugs.

Once logged in, in the front page, there is a "Managing you Account" section where you have "Show all open reports that I reported". Just take note that this are *open* reports, not those that have been resolved/fixed/closed. To find closed bugs, you can use the Advanced search form (from the front page or the menu at the top).

- Searching for a specific bug is a pain as the involved component (ie: kmail,
kopete, plasma...) is not a column when the bugs are shown.

Not sure what you mean.

- After posting a comment in a bug, that bug dissapears and the next one
appears... ¿?

Again, not sure what you mean. What "next one"? I just commented on a bug right now and it didn't go to a "next one".

- Rating a bug/wish is done in a separate section instead of the bug/wish
report itself.

If you mean voting for a bug, at the top (before all the comments) there is a "Vote" link. Of course for convenience you have a page which lists all bugs you've voted for.

And I the only who doesn't feel confortable with current bug tracker?
Is there any aim to change/improve it?

KDE is using Bugzilla for it's bug tracker. It is not a homebrew application. So whatever limitations you're bumping into, almost all users of Bugzilla also experience. There is always an ongoing communication between KDE and Bugzilla on how it can be improved. You can find out more about them at http://www.bugzilla.org/

Thanks for your attention to details and your desire to improve the KDE experience. :)

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

About KDE bug tracker

2009-09-19T09:25:42Z

Hi, in my opinion KDE's bug tracker is the worst I've ever seen:

- I *never* find my reported bugs.

- Searching for a specific bug is a pain as the involved component (ie: kmail,
kopete, plasma...) is not a column when the bugs are shown.

- After posting a comment in a bug, that bug dissapears and the next one
appears... ¿?

- Rating a bug/wish is done in a separate section instead of the bug/wish
report itself.

And I the only who doesn't feel confortable with current bug tracker?
Is there any aim to change/improve it?

Regards.

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: KDE4 Multiple Monitor support

2009-09-15T22:34:07Z

On Fri, Aug 21, 2009 at 2:28 PM, Ross Linder <info@...> wrote:
> It would appear that this is impossible to achieve with KDE4. I think this
> is a serious lack of feature.

Hi Ross,
I believe I have the set-up you are after [1]. I'm using the
opensource ( ati ) drivers, and then used xrandr [2] to adjust it to a
side-by-side layout.

Hopefully it'll work for you too.

[1] http://img40.imageshack.us/img40/2081/dualmonitor.png
[2] xrandr --output VGA-0 --mode 1280x1024 --pos 0x0 --rotate normal
--output DVI-0 --mode 1366x768 --pos 1280x0 --rotate normal
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Benchmarking KDE?

2009-08-22T02:46:14Z

On Saturday 22 August 2009 00:47:42 hajma wrote:
> Is there any tool that would help me measure the impact of different
> tweaks on KDE performance?

Well it depends on how deep you want to get into the code ;) I would suggest
that you look into the QTest Benchmarking framework and write a few unit
tests. This will benefit everyone if you do it this way ;)

-Andrew
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Benchmarking KDE?

2009-08-22T01:47:35Z

On Sat, Aug 22, 2009 at 1:47 AM, hajma<tropikhajma@...> wrote:
> Hi,
> in the kde-solaris project we've got to a point where vast majority of
> KDE 4.3 builds*, so now we're turning to fixing crashes and other
> lower priority stuff.
> Generally KDE feels slower on OpenSolaris than on Linux so I'd like to
> try some optimizations.
> Is there any tool that would help me measure the impact of different
> tweaks on KDE performance?
> TIA

There is the tool called kstartperf which tells you the time it took a
KDE app to start up... I think you could make a reasonably reliable
startup test script around that ;-)

> hajma
>
> * a live DVD at http://www.genunix.org/dist/korona/Korona-0.0.2.iso
> _______________________________________________
> kde-quality mailing list
> kde-quality@...
> https://mail.kde.org/mailman/listinfo/kde-quality
>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: KDE4 Multiple Monitor support

2009-08-21T19:03:51Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shaun Reich wrote:
> (b) disables compositing permanently while Xinerama is enabled

IIRC, Xinerama is deprecated for this and many other reasons. Xrandr is
its replacement.

https://lists.ubuntu.com/archives/ubuntu-x/2007-November/000059.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJKj1IGAAoJEIsblWe5kJ+jIVoH+weQOgYbtpQxy4wdeVV2GoLO
Sojpc+HvDJE/syN3bsIW/HnmivPehCGKjqL7Sy0XkSRwfyMiCtu4t+bav/vlQrq0
boLwOdSysQ09LnnsAfrKD3zV6CZ8ggSzSjyIVYXC9VZRcD1/nL8FbGX16WmbMeAA
kI4QbNsup6XKPXmr1OC2kaKBtDkFQOIlt6ez4GzKbu+lB2Ruzmfpzpy6wVxKpnnp
wJDIOV74PXwvCouGNZBzr1zn2c5x6Ww13iP084Nk2qFLt9U2+ScUEiy6sCE/pGUX
yd2REt1caImzrYexWwI9ExYWCyhOft3smPAR+qej0knelHIS8rE+wnIz+BRryrc=
=o5p+
-----END PGP SIGNATURE-----
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Benchmarking KDE?

2009-08-21T16:47:42Z

Hi,
in the kde-solaris project we've got to a point where vast majority of
KDE 4.3 builds*, so now we're turning to fixing crashes and other
lower priority stuff.
Generally KDE feels slower on OpenSolaris than on Linux so I'd like to
try some optimizations.
Is there any tool that would help me measure the impact of different
tweaks on KDE performance?
TIA

hajma

* a live DVD at http://www.genunix.org/dist/korona/Korona-0.0.2.iso
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: KDE4 Multiple Monitor support

2009-08-21T07:09:13Z

2009/8/21 Braden Mcdorman <bmcdorman@...>:

> Twinview works almost flawlessly for my different resolution monitors, but X
> itself seems to be
> the root of most of my problems If I have them. Supposedly the Nvidia
> drivers make some funky
> changes to the X.org config file. But I can have different panels on each
> monitor, etc.
>
> Thanks,
> Braden McDorman
>
> On Thu, Aug 20, 2009 at 11:28 PM, Ross Linder <info@...> wrote:
>>
>> In KDE3 it is possible to use multiple monitors WITHOUT Xinerama, in this
>> mode both desktops look like complete sessions, each has its own pannel,
>> its own workspace manager, and importantly can run at different
>> resolutions.
>>
>> It would appear that this is impossible to achieve with KDE4. I think this
>> is a serious lack of feature.
>> _______________________________________________
>> kde-quality mailing list
>> kde-quality@...
>> https://mail.kde.org/mailman/listinfo/kde-quality
>
>
> _______________________________________________
> kde-quality mailing list
> kde-quality@...
> https://mail.kde.org/mailman/listinfo/kde-quality
>
>

Yeah, I just recently (yesterday) set up a dual head LCD desktop (with
nvidia), so I enabled Xinerama because it sounded good and.. well, it
was an extra option, so I figured I had might as well...

Needless to say, I was disappointed when I couldn't access my virtual
terminal well I could...but I could only see a black screen, but I
could log in and stuff(I knew because when I logged in, I could hear
my hard drive being used)..

I also found out that compositing wasn't working..

So in conclusion..I think the moral of the story is to not have
Xinerama enabled, because it seems to do the following:

(a) seems to do nothing for extra features or usefulness

(b) disables compositing permanently while Xinerama is enabled

(c) disables your ability to access virtual terminals

So yeah, I really don't see a reason for using it... I was under the
impression that it allowed dragging of windows between each separate X
session... but TwinView does the same exact thing... in fact, I can't
find any missing feature switching from Xinerama to TwinView, only
extra features (well..more like Twinview having a lack of inability
to use features).

I recommend, as Braden said, to use TwinView, there is nothing to
lose, only to gain from what you lose with using Xinerama. The mouse
moves between them and everything, flawlessly...

Now I just have to figure out how to (if I can) get the virtual
terminals (via GRUB2) to display at a nice and high resolution... with
1600x900 for each monitor being the native (and current), 1280x1024
does not cut it for a virtual terminal, as it's huge...

It works absolutely beautifully for me, the only thing that I wish it
had, was Plasma to have the ability to copy plasmoids, but I will just
have to do it manually (I like the idea of 2 activities separate, but
don't like the idea that I have to do twice the work of setting up an
activity)

--
Innumerus Gratiae,
Shaun Reich
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: KDE4 Multiple Monitor support

2009-08-21T03:41:08Z

Twinview works almost flawlessly for my different resolution monitors, but X itself seems to be
the root of most of my problems If I have them. Supposedly the Nvidia drivers make some funky
changes to the X.org config file. But I can have different panels on each monitor, etc.

Thanks,
Braden McDorman

On Thu, Aug 20, 2009 at 11:28 PM, Ross Linder <info@...> wrote:

In KDE3 it is possible to use multiple monitors WITHOUT Xinerama, in this
mode both desktops look like complete sessions, each has its own pannel,
its own workspace manager, and importantly can run at different
resolutions.

It would appear that this is impossible to achieve with KDE4. I think this
is a serious lack of feature.
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

KDE4 Multiple Monitor support

2009-08-20T21:28:28Z

In KDE3 it is possible to use multiple monitors WITHOUT Xinerama, in this
mode both desktops look like complete sessions, each has its own pannel,
its own workspace manager, and importantly can run at different
resolutions.

It would appear that this is impossible to achieve with KDE4. I think this
is a serious lack of feature.
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Automated Unit tests for the Future

2009-08-13T03:38:28Z

On Thursday 06 August 2009 10:34:19 Andrew Manson wrote:
> Hi everyone ,
<snip>

Sounds great Andrew, looking forward to it reaching fruition. I think it would
definitely be good to have a system when people can sign up to a commit-digest
equivalent for monitoring build or test failures and if people who haven't
signed up can be emailed regardless to hopefully help people learn when they
break stuff for other platforms.

Nice work!
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Automated Unit tests for the Future

2009-08-11T13:12:27Z

On Thursday 06 August 2009, Michael Leupold wrote:
> Andrew Manson wrote:
> > 4) from what I hear the kind people at
> > http://www.cdash.org/CDash/index.php have already offered to host the
>
> AFAIK they already did (http://www.kdedevelopers.org/node/3531) but last
> time I checked it wasn't getting used. Now it seems to be gone - at least I
> can't find it any longer.

It's at http://my.cdash.org now:
http://my.cdash.org/index.php?project=kdelibs

Alex
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Automated Unit tests for the Future

2009-08-06T13:10:15Z

Hi,

On Thursday 06 August 2009, Andrew Manson wrote:
> Hi everyone ,
>
> I'm a Marble developer and have just started to think seriously about unit
> tests and test driven development, possibly a bit late in the game but
> better late then never! I was surprised to see that we already had some
> unit tests in Marble but what was worse was that the core developers (
> including myself ) were "Surprised to see" that more than 50% of the tests
> failed. This is why I've come to you lot, hopefully to spark some
> discussion and get some things done ;)

Nice, I'd also like to get things going in this regard.

> The shocking thing about ^^^ is that the core developers were completely
> unaware that the unit tests were failing, which i find a bit odd when there
> are some pretty good Dashboard programs out there that can display and
> notify about the results of unit tests. I would really like to see one of
> these programs being used in a big way in KDE sooner rather than later so
> thats why I spend most of yesterday chatting with someone that knows much
> more about this stuff than I do. Sorry in advance if this turns out to be a
> very long email.
>
> Over the course of yesterday's discussions we have identified two major
> "styles" of unit test dashboard system. 1) a distributed model using
> something like CTest and CDash to display the results or 2) a centralised
> model where the build system is "part" of the *dedicated* unit test running
> system and the dashboard, like buildbot and CruiseControl . Each have their
> merits and hopefully we can discuss which one would be "more right" for
> KDE.
>
> For the centralised model we have a few organisational problems, mainly
> that we would need a (dedicated ) server to be provided so that we could
> run the build and display the results. This may not be so difficulty
> because I know that "Dirk" has a system like this setup already where the
> build results are displayed here: http://ktown.kde.org/~dirk/dashboard/ but
> this currently only works for displaying the actual result of the build and
> does not include unit tests. Using this model to incorporate unit tests
> shouldn't be too hard but it might cause an organisational nightmare for
> the sysadmins ( who have a hard enough time already ). On the other side of
> that, if we used a buildbot system and some of the new cool buzzwords in
> computer science like "distributed virtualised cloud computing" we could
> make a really cool system that would be able to check the build of KDE on
> Linux, Windows and Mac. This would be pretty cool but like i said an
> organisational nightmare.
>
> The other possibility is that we could use the distributed unit test
> reporting model that is currently incorporated by the CTest and CDash
> system. This is favorable for a number of reasons:
> 1) we are currently using CMake so adding CTest support is *easy*!
> 2) we don't have to have a centralised build system because any time the
> unit tests are run on any computer the results are submitted to the CDash
> dashboard

Nevertheless having some big central machine ideally running a bunch of
virtual machines, i.e. one with Windows, with OSX, FreeBSD and Solaris would
be nice :-)
I guess this would mean an Apple server...

> 3) to set up the CDash system we would only need to add a few
> CMake variables to our CMakeList.txt files and we will be submitting
> results to a database in no time
> 4) from what I hear the kind people at http://www.cdash.org/CDash/index.php
> have already offered to host the CDash installation so our sysadmins would
> be able to take it easy.

Yes, Kitware offers free hosting for free projects at my.cdash.org.
I have already set up dashboards for kdelibs, kdepimlibs, kdesupport and
automoc. I still need to document this somewhere, and I need help with
running the builds :-)

> There are a lot of good points for using the CDash system but there is one
> pretty big problem with it that may render our test results somewhat
> useless. The fact that we are now starting to use the QtTest system makes
> things very easy for us but it means that each QtTest executable will be
> regarded as a single test by the CTest system. This is conceptually wrong
> because each QtTest executable contains many sub tests that can fail or
> pass independently of the single QtTest executable. Currently the CTest
> system only creates a test result on the test executable level which means
> that the results may not give any direct information as to why the test
> failed. Some may say that this is only a small detail and results on the
> executable level are "good enough" but if we are building a KDE-wide build
> system we should at least try and get it as close to perfect as we possibly
> can, or at least move in that direction. This problem could possibly be
> fixed with a patch to the CTest system but that would require some effort
> by someone far smarter than myself ;)

I don't think it would be too hard.
And you are not the first one with this issue. Not using ctest/cdash because
of this one issue would be stupid, instead we (the people interested in
testing) should contribute and write a patch :-)
I can commit to the cmake (ctest) cvs, so this wouldn't be a big problem.
Not sure whether it would also require modifications in cdash. I don't have
commit access there, but Julien, the main developer, is usually very
responsive.

Alex

P.S. I'm offline now until Tuesday
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: Automated Unit tests for the Future

2009-08-06T04:43:25Z

Andrew Manson wrote:
> 4) from what I hear the kind people at
> http://www.cdash.org/CDash/index.php have already offered to host the

AFAIK they already did (http://www.kdedevelopers.org/node/3531) but last
time I checked it wasn't getting used. Now it seems to be gone - at least I
can't find it any longer.

Regards,
Michael

_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Automated Unit tests for the Future

2009-08-06T02:34:19Z

Hi everyone ,

I'm a Marble developer and have just started to think seriously about unit
tests and test driven development, possibly a bit late in the game but better
late then never! I was surprised to see that we already had some unit tests in
Marble but what was worse was that the core developers ( including myself )
were "Surprised to see" that more than 50% of the tests failed. This is why
I've come to you lot, hopefully to spark some discussion and get some things
done ;)

The shocking thing about ^^^ is that the core developers were completely
unaware that the unit tests were failing, which i find a bit odd when there are
some pretty good Dashboard programs out there that can display and notify
about the results of unit tests. I would really like to see one of these
programs being used in a big way in KDE sooner rather than later so thats why
I spend most of yesterday chatting with someone that knows much more about
this stuff than I do. Sorry in advance if this turns out to be a very long
email.

Over the course of yesterday's discussions we have identified two major
"styles" of unit test dashboard system. 1) a distributed model using something
like CTest and CDash to display the results or 2) a centralised model where
the build system is "part" of the *dedicated* unit test running system and the
dashboard, like buildbot and CruiseControl . Each have their merits and
hopefully we can discuss which one would be "more right" for KDE.

For the centralised model we have a few organisational problems, mainly that
we would need a (dedicated ) server to be provided so that we could run the
build and display the results. This may not be so difficulty because I know that
"Dirk" has a system like this setup already where the build results are
displayed here: http://ktown.kde.org/~dirk/dashboard/ but this currently only
works for displaying the actual result of the build and does not include unit
tests. Using this model to incorporate unit tests shouldn't be too hard but it
might cause an organisational nightmare for the sysadmins ( who have a hard
enough time already ). On the other side of that, if we used a buildbot system
and some of the new cool buzzwords in computer science like "distributed
virtualised cloud computing" we could make a really cool system that would be
able to check the build of KDE on Linux, Windows and Mac. This would be pretty
cool but like i said an organisational nightmare.

The other possibility is that we could use the distributed unit test reporting
model that is currently incorporated by the CTest and CDash system. This is
favorable for a number of reasons:
1) we are currently using CMake so adding CTest support is *easy*!
2) we don't have to have a centralised build system because any time the unit
tests are run on any computer the results are submitted to the CDash dashboard
3) to set up the CDash system we would only need to add a few CMake variables
to our CMakeList.txt files and we will be submitting results to a database in
no time
4) from what I hear the kind people at http://www.cdash.org/CDash/index.php
have already offered to host the CDash installation so our sysadmins would be
able to take it easy.
There are a lot of good points for using the CDash system but there is one
pretty big problem with it that may render our test results somewhat useless.
The fact that we are now starting to use the QtTest system makes things very
easy for us but it means that each QtTest executable will be regarded as a
single test by the CTest system. This is conceptually wrong because each
QtTest executable contains many sub tests that can fail or pass independently
of the single QtTest executable. Currently the CTest system only creates a
test result on the test executable level which means that the results may not
give any direct information as to why the test failed. Some may say that this
is only a small detail and results on the executable level are "good enough"
but if we are building a KDE-wide build system we should at least try and get
it as close to perfect as we possibly can, or at least move in that direction.
This problem could possibly be fixed with a patch to the CTest system but that
would require some effort by someone far smarter than myself ;)

Sorry again for the really long email, but i think that this really needs to
start getting discussed. I'm CCing this email to kde-devel and kde-quality so
that we can get as many people into the discussion as possible. I personally
believe that this discussion should be on the kde-buildsystem mailing list so
lets try and keep the discussions there ( feel free to correct me on this one
).

Happy coding!
-Andrew

--
Andrew Manson
Working for Marble Desktop Globe http://edu.kde.org/marble/
Implementing an OSM Annotation layer http://tinyurl.com/OSMMarble
Blog http://realate.blogspot.com
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: [OT] Some bug in KDE4 about the keyboard?

2009-07-23T17:30:22Z

El Miércoles, 22 de Julio de 2009, Iñaki Baz Castillo escribió:

> El Miércoles, 22 de Julio de 2009, Alex Fiestas escribió:
> > I'm so so sorry if what I'm going to ask is an stupid question but,
> > maybe....
> > Do you have the feature Sticky keys activated? because this feature
> > produce the same behavior you are describing....
> >
> > You can check it at: systempreferences->Accessibility->Modifiers Keys
> >
> > (It could sound stupid, but it happens to me at gcds).
>
> It's not stupid at all ;)
>
> Yes, I had them enabled (dissabled now to test it). However, I cannot
> imagine how they were enabled when I'm just writting as usual...
>
> But let's check :)

Alex, really thanks a lot since that was exactly the reason of my issue !!

However, it must be a bug somewhere since it just occurred after the alst
upgrade and I've never changed my condiguration related to "Modifiers Keys".

Thanks a lot ;)

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

Re: [OT] Some bug in KDE4 about the keyboard?

2009-07-22T11:48:15Z

El Miércoles, 22 de Julio de 2009, Alex Fiestas escribió:
> I'm so so sorry if what I'm going to ask is an stupid question but,
> maybe....
> Do you have the feature Sticky keys activated? because this feature produce
> the same behavior you are describing....
>
> You can check it at: systempreferences->Accessibility->Modifiers Keys
>
> (It could sound stupid, but it happens to me at gcds).

It's not stupid at all ;)

Yes, I had them enabled (dissabled now to test it). However, I cannot imagine
how they were enabled when I'm just writting as usual...

But let's check :)

Thanks a lot.

--
Iñaki Baz Castillo <ibc@...>
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality