Greetings. kde-pim and kde-devel are now among the lists that are covered. Juergen Appel once again contributed to this edition. Thanks! Not a whole lot to cover today in amount of posts, but the ones that are there are REALLY there, so let's just get right down to it...
Till Adam wrote:
While debugging the mass delete crash in KMHeaders::msgRemoved I was deleting and moving/copying about oodles and oodles of messages a lot. If you move 5000 or so messages the gui freezes during that time and there is no visual feedback that an operation is in progress at all, which is somewhat suckish. I am sure you are all aware of that, I just wanted to kick off a discussion as to how to remedy that. Should I/someone just add a progress thingie to KMMove|CopyCommand::execute and redraw the screen every n messages, in other words process the list in chunks? Would it make sense to have that in KMCommand or somewhere? Is there already some plan for how to do this, maybe?
To which Ingo Klöcker responded:
AFAIK there's no plan yet. It would make sense for all operations which can take a lot of time. So it should also be done for changing the message status. A possible solution is to call a singleshot timer (cf. QTimer) after every n messages. On timeout the next chunk would be processed. One difficulty is that you will have to deal with repeated execution of the same or a conflicting (move <-> delete) command. Currently always only one KMCommand can be executed at a time. Either we continue to deny the execution of multiple commands by ignoring all further commands during the execution of a command or we queue multiple commands.
To which Till again responded:
Oh, I was thinking of doing it inside the ::execute calls. We have the length of the list, so we could just update the screen every list.length() modulo some n inside the execute loop. That would have to be duplicated in the three or so commands that need it.
Ingo started that it would be very bad design. To which Stephan Kulow said,
I was toying with the idea of deploying GNU pth. It gives the advantages of
threads without the disadvantages (hard to debug, easy to crash when you're
not be careful). I would play around with it and see what changes in
architecture would be needed and if it works at all. But I think, in the
long run, having several execution paths would ease the code quote a lot
(if you think about it, single shot timers aren't easier to debug than threads
:)
Ingo then proposed possibly separating kmail into a frontend and a backend,
where the frontend would be the GUI and the backend would handle the meatier
stuff. Stephan generally agreed, but proposed an option so that you could
have a full kmail without the daemon stuff - Interprocess communication could
slow things way down, he said.
In a separate reply to Ingo, Till said that it would be a bad design, and proposed a command queue type structure.
And Don Sanders said:
While just updating the screen would not be a perfect design I think it would be a nice improvement over the current situation and therefore a good idea.
Datschge wrote:
Hello KDE mailing lists members,
I've been bug hunting on b.k.o for the last couple of weeks and really like the technical features of bugzilla and the custom KDE interface. But I still thought that we can make it even better improving the usability and understandability. So I went ahead last week and changed a couple of templates together with Daniel Naber who also fixed further ones of them and committed all changes promptly (thank you!).
Following are the changes we did:
[Header] Links are now a little more descriptive.
[Front page] Added a whole bunch of imo useful links and "tools", changed its grouping and ordering to reflect their popularity and importance. I personally would like to emphasise the importance of the newly added "idling open reports" tool near the bottom of the front page. It will allow everyone to easily thin the huge amount of old bug and wish reports which are often obsolete for some time already and can be easily closed as soon as someone is aware of them.
[Actions panel] Changed "Edit prefs" and "Log out (username)" into complete links instead only parts of them.
[Bug pages] Completely "redesigned" the "bug list" navigation. "Query page" and "Enter new bug" has been removed since they are in the "Location" line at the top already. The number of the current bug, the whole amount of bugs in the current list and a link to that list has been combined in one easy to understand sentence. "First" and "Previous" now appear together on the left and "Next" und "Last" on the right edge and are shown respectively deactivated on the first and last bug page. Furthermore the top right infobox now also contain the numbers of votes including links to an overview over all casted votes as well as to vote yourself. "View Bug Activity" and "Format For Printing" don't show up big anymore, and the attachment table at the bottom resembles the infobox now.
[Query page] Tried uncluttering the page without removing features. Every feature is represented in logical sections. Now we can have some discussion what features can be combined/removed and how to add features like full text search etc. =)
[Search result page] Made Time/Date display friendly. ;) Made Bugzilla's "little mind message" more useful by suggesting to edit the existing search to narrow down the result including a link back. Reworded and reorganized navigation links now shown at the top and the bottom (good for long lists).
[Vote page] Added link back to bug page on casted votes pages, added text both at the top and the bottom and button after the text on personal votes page.
What else I personally would like to see improved:
- Logging in should bring you back to the point where you decided to log in, not to the complex query page. (Bugzilla issue, see http://bugzilla.mozilla.org/show_bug.cgi?id=83044 )
- The Bug Report Wizard should show the number of steps necessary to finish a report and at what point the user is.
- Searching for duplicates in the wizard should be done early in instead later[Query page] Tried uncluttering the page without removing features. Every feature is represented in logical sections. Now we can have some discussion what features can be combined/removed and how to add features like full text search etc. =)
- Extend "weekly summary" to include links to each product's chart and wishlist making it an even better starting point for getting product specific stats and bugs.
- Make "report ownership counts and charts" look more pleasing and logical and remove non-working "most recently doomed" entry (or is its purpose intended to be unknown for users like me?).
I hope you like those changes and am looking forward to hearing your comments and suggestions. Thank you for your attention.
There was a mix of favorable and unfavorable reviews of these changes, the most common being that there is much less horizontal space being used. Datschge said that he would try to fix this. All were appreciative, however.
Kevin Krammer forwarded on a nice note from Tim Brodie:
...and a note of appreciation.
Our company adopted KDE as our official desktop environment over a year ago. I've just upgraded to v3.1 and I'm just so impressed.
We introduced our users to KDE with v2. None of them had used any other desktop than the MS incumbent. Yet all were able to use KDE with very little training. This new release is just thrilling, with many of the niggly issues being smoothed right out and with the whole UI being so good.
I've worked with many systems, from mainframe 3270 terminals, Vax/VMS on VT220, Mac's, Motif on HP/UX, Windows, S/36's... you name it. But you'll have to pry KDE out of my cold, dead fingers. :-) Well, maybe that's a little far fetched... ;-)
Anyhow, well done to a team of people doing an exceptional job!
Best regards... Tim
Carl G Lewis came to bring Christmas-feelings to David Faure saying:
There are some kword patches here:
http://members.optushome.com.au/carllPatch 3 fixes some compilation warnings seen with gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) on RH9.
Patch 2 fixes a bug related to selecting the rows/columns of tables by moving the mouse slightly to the left/above a row/column.
[..]
Patch 1 is rather large (1100 lines or thereabout) but all it does is make the m_row, m_col, m_rows and m_cols member variables of the Cell class private. This meant a few changes in other files apart from kwtableframeset.*
Accessor functions have been provided and all code changed to use these. This increases readability and makes it easy to find all the places that the Cells are being manipulated.
I have also written a TableIterator class, which makes the m_cells conversion easier because all simple traversals of m_cells can be changed with just 1 line of code. The TableIterator makes use of the fact that the Cell members are private, but it's not ready yet.
So, KWord got presents from the gifted Carl. David responded:
Wow, it feels like Christmas :)
Very good patches, I'm happy with all of them.
In the further discussion, various aspects of these patches and the future progress were examinated. Carl was granted a CVS access to delivery coming gifts himself. Welcome on board ;).
Christmas is one of the most anticipated celebrations for a lot of children. This is for several reasons. One is the gifts. Pierre Souchay knows this and joined in handing out presents, saying:
I've developed a kfile-plugin for OOo files. It supports all meta-datas of the meta.xml file in OOo files in RW, including meta:user-defined (data defined by user)
It may be inserted in the KOffice packages or maybe in the KDE CVS Tree. It currently compiles in the koffice/tools/kfile-plugins/ooo path, you will find it at : http://bad.sheep.free.fr/kfile-plugin-ooo.tgz.
I dont currently know any bug.
The plug-ins were appreciated and CVS access was given to Pierre:
Thank you for all,
I have requested a CVS account.
I will add some small features to the kfile-plugin and then look at KOffice.Is there an area where to look first, where do you need additionnal developers (I do not draw icons, sorry :) ?
David Faure pointed out that Pierre could draw his attention to the OpenOffice export filter, which would enable the project to switch to the OO-file format later on.
As referred to in the
As prophecied, our needs are taken care of. Sven Lueppken tells the story:
Hi again!
Ok, I've got the icons now, at least the app-icons, but Everaldo said that he would create toolbar icons too. I can commit as soon as I've got the time and as soon as David gives me his "ok" ;)
Joyful was this received.
KPDFIMPORT is KOffice's import filter for .pdf-files, or at least the name makes me think it is. However, the filter is not included in the recent KOffice beta release. That is because..but listen to the developer Nicolas Hadacek himself:
I'd like to have the filter in the next version of koffice. The problem is that I haven't connection to the internet for the last 2 months (I will probably be connected by the end of this week...).
Luk Tinkl, the KOffice release manager - or at least his signature makes me think he is - agreed to the idea to include it into the next KOffice release. Furthermore, Sidoine Mosiah Pierrel reports version 0.3 - 0.4 working fine. Or at least he makes you think it is. State of the art is version 0.5 or already beyond.