Hi devs,
I've got a question for the KDE/Qt specialists:
I was just wondering whether the automoc version 0.9.88 is actually still able to work with Qt3…
(If I am not completely mistaken an automoc 0.9.88 must have worked just fine building kmymoney 1.0.5 still half a year ago on MacOSX through MacPorts…)
Greets,
Marko
Darrell, David, François,
I found that the first part of the commit c94de3af causes incorrect
computation of unread messages in KMail - in the tray icon. Every time
you switch to any folder, the number of unread messages is increased.
I could easily revert that part, but I fear that it will return a problem
with gcc 4.7. You look at it? I do not know if a problem does not even
rename "it" in the second part - for KOrganizer.
Slávek
--
All,
I have an idea to make the killer-app basket-notepads, that much better. When
entering notes, I use indent levels to format information in basic
heading/subheading style within simple text baskets. Basket currently lacks an
indent feature such as kwrite/kate have where pressing enter starts the next
line with the indent of the current line (similar to vim ':set autoindent')
Since the code exists for kwrite/kate/quanta+ how hard would it be to add that
capability to basket? I guess it would be adding the kpart feature to whatever
the 'text edit' widget in basket is. Anybody looked at that code in kwrite/kate
to know what it is called or how difficult it looks to implement in something
like basket?
That would be a killer addition to this killer app. Screenshot example:
http://www.3111skyline.com/dl/dt/trinity/ss/basket-indent.jpg
--
David C. Rankin, J.D.,P.E.
Just a heads up, the ABI for kate/kwrite broke in GIT hash 08c816f.
A rebuild/reinstall of tdelibs, followed by tdebase, should clear up any
potential issues caused by this commit.
Tim
Tim,
The manhunt had begun -- What had happened to Tim? TDE GIT -> dead, mailing
list -> dead, Tim -> ? We were beginning to worry... What's up?
--
David C. Rankin, J.D.,P.E.
Tim, All,
If we want to preserve the application building tutorials for TDE, we may want
to collect those that are applicable from kde.org before they are all removed. I
have found several instances where the examples are either gone or are labeled
to be removed. I've annotated the pages at kde.org for preservation, but in some
seeming "erase all reference to kde3" move, most are slated for deletion. (the
storage and bandwidth requirements for the tutorials are minuscule, so the need
to delete is somewhat confusing)
As food for thought, between the kde3 tutorials at kde.org and the gtk
tutorials at developer.gnome.org/gtk-tutorial/, the gtk tutorial is laid out
much more logically and thoroughly. If we do preserve some of the tutorials for
TDE user/developer reference, my vote would be to follow the gtk lead concerning
depth of explanation and layout. (not the web format, the content level)
Not priority, but I would be interested in what others think regarding
preserving/creating some developer information such as examples and tutorials to
show what is new/changed for TDE development verses KDE3 development. (T/Q
naming, etc..)
--
David C. Rankin, J.D.,P.E.
How is this key/value combination supposed to work? I have tested this on several desktop files and the app or applet still runs multiple instances.
I tested this in 3.5.10 with the same results.
Are there limited conditions under which X-DCOP-ServiceType=Unique is honored?
Darrell
Tim,
As with Libre has anyone looked at dialogs for OpenOffice? Apache
openoffice 3.4 was just released and it works great:
http://www.openoffice.org/download/
It is much.., much... more responsive that LO and avoids a couple of nasty
formatting bugs that affect line/character spacing in LO. Apache OO does have
a nice GTK file browser by default (like the tde browser), but it would be
nice to have an integrated browser for AOO as well.
--
David C. Rankin, J.D.,P.E.
Using recent GIT sources, does DrKonqi work correctly to create backtraces?
When I run crashtest in 3.5.10, DrKonqi creates a backtrace. In TDE all I get is the following message:
"This backtrace appears to be of no use.
This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
This worked some time in the past (I am the one who patched tdebase so crashtest would build).
My build scripts all use --enable-debug=full for automake and -ggdb for cmake. The build logs show that the packages are compiling with those flags and the increased package sizes are further evidence.
Yet I can't create a backtrace through DrKonqi. The crashtest binary should be sufficient to test DrKonqi.
Would somebody running a recent GIT please confirm whether they can create a backtrace with DrKonqi?
Thanks.
Darrell