>Other than that, I think R14 is ready to freeze for RC1.
Ready? Seems all I have done the past few weeks is file bug
reports. Regressions, sloppy coding, stdout/stderr problems, build
issues. We have 66 build issue bugs filed, 48 stdout/stderr bugs,
and 18 regressions.
As I keep saying, we get only one chance to get R14 right.
Darrell
Slavek,
I'm working on the systemd user session tracking bug (1902) and I'm trying to
figure out where to start chasing down how TDE knows when to kill a running
process. I've found a structure 'sigaction' - is this the central bit of data to
track through tdebase to see how/where process tracking/killing occurs?
Help wanted - great wages + benefits :)
--
David C. Rankin, J.D.,P.E.
Slavek,
Any more work on the systemd user session tracking issue? If you can give me
your thoughts on how you see it having to work, I'll try to track those
variables/functions through the tdm code (or where ever else it is hidden). What
I need to know is:
dcop will need to look for X in Y in order to close Z
you will need to get a signal/response from A to know to kill process
to kill process you will need to call B and make sure C happens
I need to know what you think that process looks like in order to begin
chasing this issue to help. Without some idea how you think this is going to
work, I'm just paddling in circles.... Do a Vulkan Mind Meld with an email and
dump your thoughts in a reply and send it along :)
--
David C. Rankin, J.D.,P.E.
i got an error building tqt, turns out the freetype header wasn't
where it was expected.
as a workaround i just did this
sudo ln -s /usr/include/freetype2/freetype/ /usr/include/freetype -v
but is there a way to pass that library path into tqt's make?
Hi Guys,
On Tuesday 18 February 2014 22:38:05 Darrell Anderson wrote:
> The primary reason I got frutrated yesterday is not my lack of C++
> skills. My frutration comes from the fact that asking for coaching
> help in this list is futile.
>
> Darrell
I belive, and I'm sure someone will correct me if I am mistaken, the
problem is that it can be very difficult to read and understand code
that has been written by a third party without documentation and/or
explanation of what a particular piece of code is supposed to do. C++
along with code resusability tends to distort perception of what is/was
intended originally. Lack of documentation within the code seems to be
one of those things that either gets ignored or overlooked by the
programmer for what ever reason.
Just my 2p's worth...
--
Best Regards:
Baron.
>Ahh not true - We have good folks like you to keep us straight,
>otherwise what
>are we all wasting our time on... :)
The primary reason I got frutrated yesterday is not my lack of C++
skills. My frutration comes from the fact that asking for coaching
help in this list is futile.
Darrell
>"apps that should work in TDE and will reflect poorly on TDE
>if included broken"
Based upon the response rate you've seen in this list, my guess is
nobody gives a hoot about Trinity's reputation.
Darrell
>I understand your frustration Darrell, and no you are not being
>mean. You are
>apparently taking the information I am posting in a way other than
>it is intended to be received.
Yesterday I spent a couple of hours trying to resolve bug report
1842. The Help button code is in place but the button does not
appear.
Not to mention that the default size of the list box window clips
half the text to be unreadable.
After several attempts to patch with my awful C++ skills, I walked
away in frustration. Then I asked myself: Does anybody use this low
quality garbage? Who actually writes such crappy software? Is there
a reason why such apps never were pulled into the main KDE trunk?
Why are we supporting junk? Why do people use such software and
then pretend the app is not half broken?
This is what I mean by "chicken shit" bugs. These kinds of bugs
never should exist in the first place.
Today I asked myself, Why am I spending time on junk? Stop building
the crappy stuff and the problem goes away. Nobody else seems to
care that this grabage is broken, why should I?
The real problem is my standards are too high. I need to learn to
accept that three round wheels and one wheel shaped like an octagon
is "good enough."
Darrell
>What if you want an actual database backend for kmymoney?
>
>In kmymoney's case "works for me" is a qualified "works for me" at
>best. The
>documentation blows up the build as well unless you specifically
>disable the pdf
>documents or install a 3rd party perl package of html2ps:
Does anybody actually use kmymoney? Somebody with knowledge who can
attest whether these additional build options hamper or cripple
usage? Is a database backend critical for usage or does the app use
an alternate method for storing data?
I have no idea because I don't use the app.
Is the emperor wearing clothes?
Darrell
>I tried KFtpgrappeb on a debian mirror, but after establishing a
>connection, it "stops" on the "fetching file lise".
>There is definitely something wrong somewhere.
I am going to be frank here and will sound harsh and mean. We are
eager to add older kde3 apps to the repo but part of me thinks we
do this with a bean-counter mindset --- to impress people how many
apps we have. From my own usage and observation I find many of
those older apps useless fluff.
We spend zero time on quality control and testing. Browse the bug
tracker --- filled with paper cut issues. Or, to be blunt, what I
call "chicken shit" issues. The bug reports all just sit there with
no attention.
David, file Yet Another Bug Report. I don't know what else to do.
Darrell