[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #9 from allan  ---
(In reply to Thomas Baumgart from comment #8)
> I tried this on my KDE4, KMyMoney 4.8 production system (this is generated
> of HEAD on the 4.8 branch).

> When I change the encoding in the dialog to UTF-16 before I select the file,
> then things seem to work properly.

Just to be clear, are you saying that you do not then see the problem I
reported, of the data being garbled?  If I ensure that UTF-16 is already
selected - displayed in the file selector - then I definitely do see the
corruption.

> I am looking at the following snippet in
> CSVDialog::readFile(const QString& fname):

Might this be a non-current git head version?  There has recently been some
reformatting of the source and I have void CSVWizard::readFile(const QString&
fname), as does the current git head.  In terms of the actual code, they are
identical in this particular area.  Just to be clear, again.

So far as the selector is concerned, then, yes, there are a couple of problems,
although if the decoding is for UTF-16, from previous activity or from setting
it prior to selecting the file, then the file should have the required
encoding.  Some tweaking looks to be necessary though.

Allan
> 
>   QFile  m_inFile(m_inFileName);
>   m_inFile.open(QIODevice::ReadOnly);  // allow a Carriage return - //
> QIODevice::Text
>   QTextStream inStream(_inFile);
>   QTextCodec* codec =
> QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum());
>   inStream.setCodec(codec);
> 
>   QString buf = inStream.readAll();
> 
> When selecting UTF-16 before selecting your file, QString buf contained the
> correct data. I verified this in the debugger and also data displayed in
> spread sheet form seemd to be correct.
> 
> Hope that helps for further investigation.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
[from Thomas]
"
Hi Allan,

you found out yourself: the BOM is not wrong, it's missing. I am sure, you 
stumbled over https://en.wikipedia.org/wiki/UTF-16.

I have not looked at the code of the CSV importer at that point, but you could 
check the beginning of the file (4 bytes) and see if the first two match a BOM 
or you find two 0x00 in those four bytes (where that would probably not work 
for Asian countries as they fill the upper byte with their characters).

Reading the data through a QTextStream allows to setup the encoding/decoding. 
Please take a look at QTextStream::setCodec() and setAutoDetectUnicode(), 
though according to the docs I have, the automatic detection should be the 
default. Maybe, you add another UI selector for the Encoding, in case you 
don't have it. See QTextCodec::availableCodecs() for a list of them. Check 
Kate/Kwrite in the Tools/Encding menu how this may look like.

So much for now. If you don't get the codec stuff going, please tell me where 
to find the relevant source code and I take a look at it.

Thomas"

[My reply]
"
I have /had -

QTextStream inStream();
QTextCodec* codec =
QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum());
inStream.setCodec(codec);

QString buf = inStream.readAll();
...
(void CSVWizard::readFile(const QString& fname) line c843)
which I nicked from Qt, I think.

I have encoding selection in the file selector.
...
QPointer label = new QLabel(i18n("Encoding"));
  dialog->layout()->addWidget(label);
  //Add encoding selection to FileDialog
  QPointer comboBoxEncode = new QComboBox();
  setCodecList(m_codecs, comboBoxEncode);
  comboBoxEncode->setCurrentIndex(m_encodeIndex);
  connect(comboBoxEncode, SIGNAL(activated(int)), this,
SLOT(encodingChanged(int)));
  dialog->layout()->addWidget(comboBoxEncode);

(bool CSVWizard::getInFileName(QString& inFileName) line c798)

I don't see a setAutoDetectUnicode().

I don't think I had auto-selection, but encoding was by manual selection
from the list of codecs, but UTF-16 seems not to work. (in my code).

Allan"

I'm afraid I'm not able to commit to coding, still.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #5 from allan  ---
Thomas suggested using Okteta to look at the data to see if the BOM was
correct.
Here are the first few lines :-
"
   22 00 4D 00  52 00 20 00  41 00 4C 00  ".M.R. .A.L.
000C   4C 00 41 00  4E 00 20 00  41 00 4E 00  L.A.N. .A.N.
0018   44 00 45 00  52 00 53 00  4F 00 4E 00  D.E.R.S.O.N. "

So, no BOM, just the data, and still mis-formatted by the plugin.

Ah, I've just checked against the Libre Office Calc file and, just looking at
the beginning, the bad one has "22 00", and the good one has "FF FE".  So, the
BOM is wrong on the bank version.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #4 from allan  ---
(In reply to allan from comment #3)
> It looks like my attempts to provide an edited sample file either produce
> rubbish, or remove whatever causes the problem.
> So, I may have to provide a complete file, but I don't wish to broadcast it,
> so would like to send it off-line.  To whom?
> 
> Allan

I've sent a gpg'ed copy to Thomas.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 371219] New: Plasma going in to visual stasis when a game that block compositing, starts

[Allan via KDE Bugzilla]

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

Bug ID: 371219
   Summary: Plasma going in to visual stasis when a game that
block compositing, starts
   Product: plasmashell
   Version: 5.8.2
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: kdeb...@metalight.dk
CC: bhus...@gmail.com, plasma-b...@kde.org

After launching a game that blocks compositing:
- Plasma panels go greyish most of the times.
- Plasma is visually frozen -clock is frozen, apps in the task list remain as
icon even after closing app.. But plasma is not frozen - it can be interacted
with, you can click the clock to get the calender and so on.. 
- Plasma content reverts to the content of the first time it happened: Say you
launch a game - plasma visually freeze, then close the game -delete some
widgets, start new game -old widgets appear -but only visually - eg. they don't
interact - like you are seeing an old kwin buffer or something - (so might be a
kwin bug..).

Reproducible: Always

Steps to Reproduce:
1. Enable "Allow applications to block compositing"
2. Start game that blocks compositing (like springrts).

Actual Results:  
Plasma visually goes in to stasis.

Expected Results:  
Plasma should get updates to the screen buffer.

System information: Intel i7-6950x, Nvidia gtx970, 32gb ram, 64bit Arch Linux,
dual monitor setup.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371180] New: A request for an additional monetary format

[allan via KDE Bugzilla]

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

Bug ID: 371180
   Summary: A request for an additional monetary format
   Product: kmymoney4
   Version: 4.8.0
  Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: csvimporter
  Assignee: kmymoney-de...@kde.org
  Reporter: agande...@gmail.com

Apart from the unusual date format, I have a further complication.
A credit to the credit card company now produces the following format -

"06 Sep","AMAZON UK RETAIL AMAZO AMAZON.CO.UK  LUX","£27.50","CR",

The plugin did have a similar capability, but I think this has very recently
been removed.

It would be very helpful if this format could be handled.


Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371177] New: Request for additional date format - no year!

[allan via KDE Bugzilla]

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

Bug ID: 371177
   Summary: Request for additional date format - no year!
   Product: kmymoney4
   Version: 4.8.0
  Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: csvimporter
  Assignee: kmymoney-de...@kde.org
  Reporter: agande...@gmail.com

My new format credit card statement causes further problems.
It produces a date with no year, like "15 Aug".

To avoid an on-going need to edit every entry, it would be good if the CSV
importer could cope with this format, please.

Thanks

Allan

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #3 from allan  ---
It looks like my attempts to provide an edited sample file either produce
rubbish, or remove whatever causes the problem.
So, I may have to provide a complete file, but I don't wish to broadcast it, so
would like to send it off-line.  To whom?

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Attachment #101617|0   |1
is obsolete||

--- Comment #2 from allan  ---
Created attachment 101618
  --> https://bugs.kde.org/attachment.cgi?id=101618=edit
UTF-16 file

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
Created attachment 101617
  --> https://bugs.kde.org/attachment.cgi?id=101617=edit
UTF-16 file

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 371069] New: CSV plugin mishandles UTF-16 files

[allan via KDE Bugzilla]

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

Bug ID: 371069
   Summary: CSV plugin mishandles UTF-16 files
   Product: kmymoney4
   Version: 4.8.0
  Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: csvimporter
  Assignee: kmymoney-de...@kde.org
  Reporter: agande...@gmail.com

My credit card company has revised their web site, and the statement importing
procedure and format has changed.

The KMM CSV importer is not happy with this new format.  All characters have an
interspersed null character (I think, probably 00). Each line is followed by an
additional line containing the same odd character.  So, the import is
incorrect.

If I import via Libre Office Calc, all is correct.  It is shown as UTF-16.  If
I load via Kate, this too looks wrong, unless I change the encoding from UTF-8
to UTF-16.  In the CSV importer, however, changing the encoding from UTF-8 to
UTF-16 makes no apparent difference and the original incorrect result still
appears.

Reloading an earlier file is as normal.

So, it appears that the import encoding has changed and the CSV plugin does not
handle it correctly.


Reproducible: Always

Steps to Reproduce:
1. Import a CSV file encoded in UTF-16.
2. The file will show the incorrect format.
3.

Actual Results:  
As above.

Expected Results:  
The UTF-16 should be handled correctly.

There may be more to this, however.  When I tried to create a file in UTF-16,
it could be imported correctly.  So, to be able to demonstrate the problem, I
have used a file from my credit card company, deleted everything except the
first line and then added a new first line of "12-10-2016,Description,1234.56"
Attachment follows.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 341669] Make MaxFPS configurable

[Allan via KDE Bugzilla]

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

--- Comment #11 from Allan  ---
Yea, I did notice too, that setting "Tearing prevention" to "Automatic" -
MaxFPS seems to be ignored.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 341669] Make MaxFPS configurable

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

--- Comment #9 from Allan  ---
I'm glad I found this page-- since unredirect disappeared I've been searching
for bug-free, tear-free and lag-free solution to a fullscreen game -on one of
my monitors.

Apparently setting tear prevention to "Never" and (manually editing the conf)
/turning MaxFPS up to 240 in KWin 5.8.1 -while leaving compositing on during
the game solves all three for me.
As a side bonus - Opera scrolling is also tear-free, same for videos..

Oddities I have noticed maybe someone can explain..?
- Fans stay off, powermizer (nvidia) stays on lowest, temperature and kwin cpu
usage is low/ change undetectable- even when moving windows about and scrolling
in Opera.. (Not in game)
- FPS "effect" says 100fps (and kwin consumes 20% cpu on a single core while
fps counter is running) - I guess it's just the highest it can measure.. For
when actually setting maxfps to 100 - massive tearing appear.
- Zero fps loss in game, in fact there was a slight performance GAIN in the
game!? I had expected to lose performance due to the massive blitting needed -
instead performance in game went up about 2-5%.. I tried turning compositor
on/off several times to recheck..

(Game engine is springrts and gpu is gtx970.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 345473] Double click on titlebar to maximize suddenly stops working

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

--- Comment #45 from Allan  ---
Woohoo, I figured out why this happens. :D

-Single click initiates the "double click".
..Ages pass;
-User tries to doubleclick, -BUT the first of these clicks is part of the
previously initiated double click..


You're welcome.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 370413] Vertical panels cant be clicked in the screen corners, when compositor is not enabled on startup

[Allan via KDE Bugzilla]

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

--- Comment #6 from Allan  ---
It does not seem to me that anything is being moved.

Toggling compositing on/off with shift+alt+f12 doesn't toggle the bug, unless
kwin is launched with disabled compositing - then indeed it does toggle the bug
as well! - without panels moving.

It is just that single 1 pixel- not the whole side, that can't be clicked,
please understand:
-That when moving the mouse 1 pixel in ANY direction away from the corner but
still aligned with any side makes the button clickable - that would NOT happen
if the panel was moved, then the whole side would be un-clickable. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 370413] Vertical panels cant be clicked in the screen corners, when compositor is not enabled on startup

[Allan via KDE Bugzilla]

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

--- Comment #4 from Allan  ---
If i move the mouse 1 pixel in any direction away from the corner, the Kmenu
icon lights up - and I can click it!

Starting kwin with compositing disabled is the essential part:
$ xprop | grep _NET_WM_NAME
_NET_WM_NAME(UTF8_STRING) = "Desktop — Plasma"

Enabling compositing with shift+alt+f12 and running xprop again:
_NET_WM_NAME(UTF8_STRING) = "Plasma"

Disabling compositing with hotkey again reverts to bug, BUT -starting with
compositing enabled never triggers this bug, even after disabling it with
hotkey!

Nothing moves around or seems to get covered or anything after hotkey is
pressed.

Try it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 370413] Vertical panels cant be clicked in the screen corners, when compositor is not enabled on startup

[Allan via KDE Bugzilla]

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

--- Comment #2 from Allan  ---
More things I tried btw, bug persists:
- I did try deleting the panel and creating a new one.
- I also tried as a newly created user.
- It started after upgrade to 5.8.0
- Ironically -the only reason I start KDE with compositing disabled is to
workaround another bug I haven't posted yet. :p
- It should be easy to confirm using the steps I provided.

Output of xprop and xwininfo when clicking the problematic corners:
xprop: https://gist.github.com/metalight/97bce72c35510dba9be6c9d5086e3650
xprop: https://gist.github.com/metalight/1483a55252d224459db8929d20307b43
xwininfo: https://gist.github.com/metalight/9a38d04fa4cbd83b21e95f3771f863e2
xwininfo: https://gist.github.com/metalight/2a5515e534f6ac363cdde40c8ffe2042

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 370413] Vertical panels cant be clicked in the screen corners, when compositor is not enabled on startup

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 370413] New: Vertical panels cant be clicked in the screen corners, when compositor is not enabled on startup

[Allan via KDE Bugzilla]

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

Bug ID: 370413
   Summary: Vertical panels cant be clicked in the screen corners,
when compositor is not enabled on startup
   Product: kwin
   Version: 5.8.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: kdeb...@metalight.dk

After restarting kwin with unchecked "Enable compostitor on startup" and with a
vertical panel going all the way from top to bottom of screen, covering too
corners. -I can not click the K-menu and the clock when clicking in the screen
corners - moving the mouse just 1 pixel away from the corner works.
When enabling compositor with shift+alt+f12, the corners respond again.
And if KDE is started with compositor enabled, then disabling compositor with
shift+alt+f12 - clicking also works normally.
- So it only happens when compositor is disabled on startup.

Reproducible: Always

Steps to Reproduce:
1. Uncheck "Enable compositor on startup" (System settings -> Display & Monitor
-> Compositor"
2. Move your panel so it is aligned with the left side of the monitor covering
both left corners, - I have K-menu in the bottom of this panel and Clock in the
top..
3. Restart KWin (re-login/reboot/kwin_x11 --replace)
4. Try opening calender (clock) or Kmenu by clicking the pixel in the left
corners.

Actual Results:  
Calender doesn't open.
K-menu (application launcher) doesn't open.

Expected Results:  
Menu/Calender should open.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Allan via KDE Bugzilla]

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

--- Comment #11 from Allan  ---
$ kwin_x11 --version
kwin 5.8.0
Bug is still there.

I recommend my previous post for the easiest way to reproduce it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Allan via KDE Bugzilla]

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

--- Comment #10 from Allan  ---
$ kwin_x11 --version
kwin 5.7.5

Easiest way to replicate the issue of not detecting double click:
1. Setup Double-click: to "Lower" under "Titlebar" and Left button: to "Raise"
"Active" under "Titlebar & Frame"
2. Have a window with visible titlebar below another window.
3. Click the titlebar to bring it to front, double click it to bring it lower,
this may actually work the first time.
4. Repeat step 3 to notice. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 368593] KmyMoney File Not opening and gives error As " Please use an older version...."

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
I fear not.  If you have no backup, then there is nothing from which to
recover.  At least, now, do make sure you have enabled automatic backups -
Settings>Configure KMyMoney>General>Global.  In addition, however, make a
practice of saving a copy file each time you finish a session.
A possibly forlorn hope or two, however.  Do a file search of your system for
*.kmy and *.kmy.* files.
Also, just in case your file is only partially corrupted, open your file in KMM
, then Save as, and set the filter there to XML files.  Then, open that file in
your browser, Firefox or whatever and look through the file to see if you can
recognise any data as your missing data, hoping that perhaps just the beginning
of the file is corrupted.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Allan via KDE Bugzilla]

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

--- Comment #9 from Allan  ---
$ kwin_x11 --version
kwin 5.7.3

Doubleclick to lower, bug still there, more often than not -tripleclick is
needed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)

[allan via KDE Bugzilla]

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

--- Comment #8 from allan  ---
(In reply to Dennis Gallion from comment #7)
> Thank you Allan for the very quick reply.  As it turns out, 4.8.0-13.3 was
> just added this morning to the openSUSE 13.2 KDE:Extra unsupported
> repository.  I installed it and good news the cpu spike and delay in posting
> ledger transactions has apparently been fixed.  Thanks!
> 
> However, I noted in the Change Log for 4.8.0 the following:
> 
> * Categories no longer have opening date, which caused annoyingerrors both
> during input and   while running the consistency check
> * Fixed some annoying consistency check errors
> 
> When I ran 4.8.0 the first time, and each time the file is saved, the
> Consistency Check is run and it is returning over uncorrectable 5000 errors,
> each indicating a posting date that is older than the opening date of the
> account.  All of the transaction data in the log is for 2007 and older; I
> can't say if there are such errors in newer data.  It may be that most of
> the errors are in data that was imported, but for a certainty I began using
> the application after the import in about 2005 so there are errors in at
> least some newer data.

The fix was specific to categories having an opening date.  You may still have
other accounts with problem dates, I'm afraid.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)

[allan via KDE Bugzilla]

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

--- Comment #6 from allan  ---
I can't really see any prospect of attempting to fix a problem on such an old
release.  Please, can't you upgrade to a current version?  4.7.2 includes
numerous bug fixes, and 4.8.0 was released quite recently.  If the problem is
still present, then there is a far better prospect of finding a fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 365139] Inconsistent localization of month names in calendar plasmoid

[Allan via KDE Bugzilla]

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

--- Comment #4 from Allan  ---
Since both the tooltip and calendar plasmoid are using the language for LC_TIME
except for the month on top, shouldn't the month also use the same language as
LC_TIME, without any trickery with LANG?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 362373] layout seems to be changed to TXT mode, losing HTML formats

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |UNCONFIRMED

--- Comment #2 from allan  ---
(In reply to CPL from comment #1)
> Even with 4.8 version, the problem still remains.

Oh, well 4.8.0 is only very recently released, with no such problem showing
up..

So, we need to consider your .kmy file.  Would you create a new, minimal .kmy
file and see if that fares any better.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 366136] New: maximized windows go beneath panel when using multiple displays

[Allan via KDE Bugzilla]

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

Bug ID: 366136
   Summary: maximized windows go beneath panel when using multiple
displays
   Product: plasmashell
   Version: 5.7.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: al...@azic.ca

If a panel is on the edge connecting two displays, maximized windows, including
quarter/half snap, will go beneath the panel.

e.g.
Display 1 on left, Display 2 on right. If panel is placed on the left edge of
Display 2, all maximized windows on Display 2 go beneath the panel.

Reproducible: Always




Same as Bug 323230 on plasma4

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #32 from allan  ---
Ah, we're on reconciliation.  It is indicating a discrepancy with cleared
transactions.  Uncleared transactions will be excluded from reconciliation.

So, in that account, click Not marked in the status (top right).  Make sure all
those transactions are cleared.

It might help in any further difficulty to just reconcile part of the account,
into smaller chunks , if that helps to show where the problem lies.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #30 from allan  ---
I made an assumption that it could be the date field that was red. Obviously
now that's not the issue.  So, I'm missing something.

Are you able to attach a screen-shot to the bug?

Allan 

In Settings/Configure KMM/Colors, a negative value may be set to show as red. 
Might that explain?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #28 from allan  ---
Actually, if the answer to the previous comment does not resolve the issue, it
would be as well to open a new bug, as your problem is not to do with rounding.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #27 from allan  ---
(In reply to sven.keller from comment #25)
> Hi Folks,
> eventually I got the RPM package provided by Opensuse. 
> I can confirm, for my "productive" file it is not working as expected.
> Great work! Thanks a lot for the effort!
> 
> However one question remains (but perhaps not related to this bug)
> I double checked and corrected all my investment transactions and the
> (visible) amount of the account also matches the amount downloaded from the
> bank.
> However it is marked in red as if it would not match?
> Is there a way to check where a potential mismatch might be?
> 
> Cheers
> 
> Sven

Can you be a bit more precise?  Is it just the date field?  If you hover the
pointer, does that produce a clue?  Might it be that the opening date for the
account is after the transaction date?  If so, edit the account's opening date
to match the oldest likely transaction.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364425] CSV import only shows checking accounts when selecting Banking

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from allan  ---
(In reply to NSLW from comment #1)
> Git commit 9c5397238947c8a010eb2e0939cb34d729dfb751 by Łukasz Wojniłowicz.
> Committed on 18/06/2016 at 17:16.
> Pushed by wojnilowicz into branch '4.8'.
> 
> Set type of banking statement to unknown during CSV import
> 
> Type of banking statement shouldn't be set to 'checkings' by default,
> bacause statement to be imported could be 'checking' but also 'credit
> card'.
> 
> M  +1-2kmymoney/plugins/csvimport/csvdialog.cpp
> 
> http://commits.kde.org/kmymoney/9c5397238947c8a010eb2e0939cb34d729dfb751

Credit card imports still do not work on 4.8.0.

The fix
"Thanks for the files. As I wrote before, CSV should be already fixed in
upcoming KMM 4.8.1. Something is wrong with QIF importer in KMM, because file
has correct type "!Type:CCard" and its account type is being incorrectly
recognized. That needs to be fixed. As temporary fix you can use workaround
provided by Allan Anderson
https://mail.kde.org/pipermail/kmymoney-devel/2016-June/016810.html;
should be present in 4.8.1.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 365802] Cannot import into Credit-Card Account

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
I reported this problem a few weeks ago.  It's the result of a recently
introduced fix.

It is possible to get round this by importing your credit card file into a
temporary checking account.  Then, select all those transactions, right click
and select move transaction to... your atual credit card account.

There is a full fix in the offing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 365307] Download

[allan via KDE Bugzilla]

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

--- Comment #4 from allan  ---
Also, if you can reproduce your problem, please supply the url which is
displaying the invalid link, so that it can be attended to.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 365307] Download

[allan via KDE Bugzilla]

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

--- Comment #2 from allan  ---
James, you do not have to register to obtain the download.  It looks like you
may have been attempting to download from an incorrect link.

I'll cc. you in case you are not subscribed to this list, just in case that
hasn't happened.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 365023] Payee listing

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
A bit more information might help us.  It sounds like you may be importing?  If
so, by what method?
What revision of KMyMoney are you using? (Help>About KMM).  Distro package or
compiled from source?
Have you considered setting up matching for the payee name you wish to use?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 364681] New: plasmall digital clock calendar shows month in wrong language when LC_TIME uses a different language

[Allan via KDE Bugzilla]

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

Bug ID: 364681
   Summary: plasmall digital clock calendar shows month in wrong
language when LC_TIME uses a different language
   Product: plasmashell
   Version: 5.6.4
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Digital Clock
  Assignee: mklape...@kde.org
  Reporter: al...@azic.ca
CC: plasma-b...@kde.org

When LC_TIME is set to a zone with a different language, the following gets
translated:

- digital clock tooltip
- digital clock's calendar weekday

but not the digital clock's calendar month.

Reproducible: Always

Steps to Reproduce:
1. change LC_TIME to different zone that uses a different language than LANG
2.
3.

Actual Results:  
see that digital clock calendar translation is incomplete

Expected Results:  
translate the month to LC_TIME's langauge like other translated elements

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 364423] New: Right click in task manager on second monitor, menu appear on first monitor.

[Allan via KDE Bugzilla]

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

Bug ID: 364423
   Summary: Right click in task manager on second monitor, menu
appear on first monitor.
   Product: plasmashell
   Version: 5.6.5
  Platform: Archlinux Packages
   URL: https://youtu.be/zskQmq-XH-4
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Task Manager
  Assignee: h...@kde.org
  Reporter: kdeb...@metalight.dk
CC: plasma-b...@kde.org

Right click to bring up menu on icon in task manager and icon-only task manager
on second monitor, menu appears on the lower right corner of first monitor.
Only happens with task manager and icon-only task manager.

I chose task manager for component in the bug report - even though it also
happens in icon-only task manager (shown in the video).

Reproducible: Always

Steps to Reproduce:
1. Setup a panel at the left side, of the right-and-below monitor. (See video.)
2. Right click an icon in task manager/icon-only task manager in the panel you
setup in (1).


Actual Results:  
Menu appears on the wrong monitor, in the lower-right corner nearest to the
right monitor.

Expected Results:  
Menu should appear near the mouse to the right of the (left-aligned) panel.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #24 from allan  ---
I know you are all up to your eyebrows, and doing fantastic work

I've just reopened this to ensure it is not overlooked, as there is still, I
think, an outstanding issue.  https://bugs.kde.org/show_bug.cgi?id=345655#c23.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #14 from allan  ---
(In reply to mhaquila from comment #12)
> As I said you, on a screen size of 1600x800 with the version 4.7.2 IT DIDN'T
> FUNCTION CORRECTLY: the screen shots are taken with this version… Because,
> as I yet said, the column width depends of the screen size.
> 
You also said, in comment #8 "My version for Linux is the 4.6.4 ...", and the
screenshots were provided in comment #5 and #6, so prior to your saying you
were on 4.6.4.

I can only repeat that 4.7.2 works correctly for me.  If it doesn't for you, I
would look to your distro/whatever.

I cannot help with a Windows problem as I gave up on that some years ago.  I
believe there have been build problems with the Widows version, but I
understand that that issue is now resolved, but probably not yet distributed.

> And I don't know at all what you put the bug resolved when it's not!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Version Fixed In||4.7.x
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #11 from allan  ---
> 4.6.4  is now very old and you are missing a lot of bug fixes and
> improvements, particularly in KMM.  I would strongly advise getting the
> latest release from the Claydoh ppa.

If you want to use KMM on Linux, then will you upgrade?  No development work
will occur if the problem has already been fixed.

I have just installed 4.7.2 again and checked this.  All columns are fully
displayed.  On a wide screen, the Details column expands, but the other columns
are still displayed correctly.  An empty Number field starts off narrow, but
expands to show the data in full.

I don't think I can say more.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #9 from allan  ---
(In reply to mhaquila from comment #8)
> My version for Linux is the 4.6.4 (KDE 4.14.2) and for Windows is the 4.7.2
> (KDE 4.12.5).

4.6.4  is now very old and you are missing a lot of bug fixes and improvements,
particularly in KMM.  I would strongly advise getting the latest release from
the Claydoh ppa.   Hopefully you don't see exactly the same behaviour on the
Windows version?

> No, it's just the problem: adding extra characters into one narrow column
> don't increase the column width which is fixed I think in percent of the
> screen size independently of the window size.

I'm pretty certain this is not the case in the latest versions.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
I don't recollect seeing that sort of behaviour recently.  You didn't say what
revision of KMM you use?

It's some while since I dabbled in this area.  Again looking for a work-around,
if you add extra characters into one of your narrow columns, does that increase
the column width?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #3 from allan  ---
(In reply to mhaquila from comment #2)
> (In reply to allan from comment #1)
> > Did you try widening the KMyMoney window?
> 
> Yes, I did. However for an easy use of the program, the window can't be
> widened more than the screen size, so resize the column seems to be
> essential.

I assume you know that you can reposition the KMM window to allow stretching to
the right?
I'm not suggesting that this is a satisfactory solution, but may be a possible
work-around.  I did actually implement a change to allow column widening, but
the current method was preferred by the developers.

Just so we have the complete picture, would you give -
The KMM version you are using -
Your screen size -
Whether repositioning is helpful.

Perhaps you could attach a screen-shot?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
Did you try widening the KMyMoney window?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #23 from allan  ---
It looks to me that https://bugs.kde.org/show_bug.cgi?id=303026 still shows its
problem.  See comment #18.  A new manually created copy of its sell transaction
still objects if a fee of 12.95 is entered.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC|kdeb...@metalight.dk|

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 349033] option to invert transaction amounts during import

[allan via KDE Bugzilla]

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

--- Comment #3 from allan  ---
Pending a proper solution, it might save a little effort when importing to
select the present amount column as Debit, and some other column as Credit. 
Then, when importing, you are given the option to accept either the debit or
credit column amount, for each transaction.  That's a bit of a fag, but it
might be easier.  The credit amount would need to be edited after import.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 348270] Cannot scroll properly in GTK3 apps after focus switching

[Allan via KDE Bugzilla]

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

--- Comment #33 from Allan  ---
(In reply to Allan from comment #32)
> Hm, that workaround is being set here and working for the few gtk3 apps i
> just tested, but isn't doing the trick for Opera, even launched from a
> gnome-terminal for testing after confirming the env is set with echo
> $GDK_CORE_DEVICE_EVENTS returning 1 in that same terminal.
> 
> Ideas are very welcome. :)

Apparently it also a bug in the current Opera (stable) separately.
Opera (beta) behaves fine.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #18 from allan  ---
Referring back to comments #3, #4,  #5, and
https://bugs.kde.org/show_bug.cgi?id=303026, does that issue now need
revisiting?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 345655] Rounding problems between checking and investment account

[allan via KDE Bugzilla]

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

--- Comment #10 from allan  ---
(In reply to Jack from comment #9)
> As I understand it, all current developer time is going to the conversion to
> KDE Frameworks.  This issue is unlikely to be addressed until after that is
> complete.  
> 
> In addition, while this may certainly be annoying, if does not make KMM
> useless.  I track several investment accounts in KMM, with multiple brokers,
> and it works just fine for me.  Remember, nobody is being paid to work on
> KMM. 

>  (You may also want to be careful about your choice of words, as "sued"
> has a particular legal implication in English, definitely in the US.)

I took that to be a typo for 'used'.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 348270] Cannot scroll properly in GTK3 apps after focus switching

[Allan via KDE Bugzilla]

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

--- Comment #32 from Allan  ---
Hm, that workaround is being set here and working for the few gtk3 apps i just
tested, but isn't doing the trick for Opera, even launched from a
gnome-terminal for testing after confirming the env is set with echo
$GDK_CORE_DEVICE_EVENTS returning 1 in that same terminal.

Ideas are very welcome. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 348270] Cannot scroll properly in GTK3 apps after focus switching

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

--- Comment #30 from Allan  ---
While I realise this has nothing to do with KDE. A workaround would be awesome
as this GTK3 bug (Opera, pavucontrol..) is still here anno 2016 with gtk
3.20.4. When mouse leaves the gtk window and comes back - first scroll event is
ignored. :-o

As unbelievable as it may sound - it even happens in pure Gnome..
- Defective by design nearly on par with scrollbar snapback in Chrome
https://bugs.chromium.org/p/chromium/issues/detail?id=377191 (Gnome folks tried
to implement this too, once.. Malice I say.. Malice!).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #14 from Allan  ---
Just testing closing a window on middle click in Enlightenment WM above
Konsole, as expected - nothing is passed down to Konsole.

-- 
You are receiving this mail because:
You are watching all bug changes.

[KScreen] [Bug 356884] kscreen messes with original xrandr config, does not respect saved config, and apply defined config only on the second try.

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

--- Comment #20 from Allan  ---
I'm also affected by this. Running KDE 5.6.4 on Arch Linux on nvidia gtx970.

Regardless if I setup my two monitors in the xorg.conf or with display and
monitor in systemsettings - the setup seems not to be respected on reboot.

Workaround: set monitors up in xorg.conf and disable kscreen2 in
startup systemsettings.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

--- Comment #5 from Allan  ---
A similar scenario, KDE 5.6.4 (Archlinux).

Double click titlebar to lower, is configured, i find that:

- Triple click is needed in 5.6.4 when just entering the window and not
manipulating it beforehand.
- Not in 5.5.5, so a regression.
- Funnily double click to lower works- when the window is first dragged or has
it’s border clicked once (not titlebar).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #13 from Allan  ---
Upgraded my KDE5 testing system to KDE 5.6.4 on Arch linux, changed the version
and platform in this bug, because it is equally affected.

Suggestion for bug fix: make middle click to close behave like left click to
close  on the close button.
- That means on release of the button + with cancel function by moving away
from the button- or bar in this case.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

   Platform|Ubuntu Packages |Archlinux Packages
Version|5.5.5   |5.6.4

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[allan via KDE Bugzilla]

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

--- Comment #12 from allan  ---
(In reply to Jeff from comment #9)
> That line:
> 
> tr.m_amount = -amount;
> 
> is the one I changed in my patch to fix my problem for "sells".  Need remove
> the negative sign.

Sorry, but I'm a bit puzzled here.  With your suggested change, to remove the
sign reversal, when the transaction imports, the result shows as a deposit of
$8.77 (positive).  Throughout the import, the negative sign is maintained, as
far as I can see.  So, I don't see "The cash account should decrease by 8.77." 
Why don't I see the result you are expecting?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[allan via KDE Bugzilla]

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

--- Comment #8 from allan  ---
(In reply to Jeff from comment #6)
> Hi Łukasz,
> 
> There is still a problem with the QIF import with your change.  My test file
> also tested the case where the commission was greater than the proceeds from
> the sale (which can happen when trading options.)  Your fix changed a "sell"
> trade that actually cost money into one that brought in money. The example
> in my test file was the "sell" of the "NFLX Aug 18 2012 110.0 Call". The
> price is 0.02, times 100 shares = 2.00. The commission is 10.77.  So income
> of 2.00, outgo of 10.77 makes the total -8.77 (as shown in the U and T
> values in the QIF file).  The cash account should decrease by 8.77. Your
> change turned that into a positive 8.77, and increased the cash account. 
> This is admittedly a corner case, and I think I am the only KMM user that
> trades options because I have made a bunch of other changes to the KMM code
> to support that.
> 
It would not have surprised me if your problem was caused by the same issue I
reported in https://bugs.kde.org/show_bug.cgi?id=362139 comment #7, with the
negative sign getting dropped.
However, the sign appears to be negative throughout the import process until -
Line 1564 in mymoneyqifreader.cpp()
"else if (action == "sell") {
d->st.m_listPrices += price;
tr.m_shares = -quantity;
tr.m_amount = -amount;
tr.m_eAction = (MyMoneyStatement::Transaction::eaSell);"

I don't profess to know anything about a sell where the commission is greater
than the proceeds of the sale.  However, I think what happens in general is
that a sell is expected to be input with no sign, and therefore the amount
needs to be set to a negative value.  So, in your case, as you have a negative
sign on input, that sign gets removed.
That seems to imply that the commission needs to negative in your case, and
reversing the signs appears to produce your expected result.
If this is all rubbish, just ignore it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

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

--- Comment #14 from allan  ---
Just to note that I discovered a possible problem with this, and documented it,
in error, in https://bugs.kde.org/show_bug.cgi?id=362139, comment #7.  See
there for follow up.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
(In reply to NSLW from comment #4)
> Statement reader did it wrong also for CSV imports (see bug #361021) so I
> made corrections to the code which seemed to help also QIF reader. Honestly
> at that time I didn't know that investment statements are imported by
> anything else than CSV and thanks to your bug and code review I see bigger
> picture now. I proposed two next patches to statement reader which now I
> must review myself because I already see mixed logic between QIF and CSV
> imports, which somehow worked by now.
> It would be nice if you could send me for testing an anonymized QIF file
> with less frequent transaction types such as "dividends" etc.
> 
> I don't know about OFX imports because valid  ACCTTYPEs are only: CHECKING,
> SAVINGS, MONEYMRKT, and CREDITLINE, and there are no investment ACCTTYPE, so
> I assume OFX doesn't support that. Correct me if I'm wrong.

The OFX specification 2.0.3 includes -
"CHAPTER 13 INVESTMENTS
OFX supports download of security information and detailed investment account
statements including
transactions, open orders, balances, and positions.
" plus a lot more in detail.
Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
Today, and the first for a while, I updated from HEAD and to ensure all was OK,
I did a CSV import of an investment file, which contained two similar entries. 
They were both CashDividends, with the main difference being that one had an
identical but negative amount.  On import, the negative sign had been dropped.
I think I've traced it, possibly,  to the recent fee patch.
In investprocessing.cpp(), at circa line 1723 -
tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs();
appears to drop the sign.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #12 from Allan  ---
(In reply to Thomas Lübking from comment #11)
> You cam make xev listen to other windows (just won't help in case this is
> related to some pointer grab):
> 
>xev -event mouse -id 

You're right - that gave nothing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #9 from Allan  ---
(In reply to Thomas Lübking from comment #8)
> press, close move, paste? that's incredibly odd - the move would at least
> have to generate a release then...
> 
> running klipper process or plasmoid? still a problem when quitting those?

No klipper.

Also - this is the behaviour straight out of the box no addons or strange
setups -you should be able to reproduce it easily just by following the steps
to reproduce in the op. I certainly can on any computer with any mouse (with 2
buttons and a scroll wheel) and any recent kde5 I can remember (sorry I first
got around to reporting the bugs now).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #7 from Allan  ---
(In reply to Martin Gräßlin from comment #6)
> at the move? That's something I would not have expected.

Affirmative, it only happens when mouse is moved during the press.
If the click is clean without any movement with the mouse, the click is not
passed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #5 from Allan  ---
(In reply to Martin Gräßlin from comment #1)
> That sounds like a bug in the applications. They react on a release although
> they never get a press event. The application should ignore that.

I happens before release of the button.
I can reproduce it by clicking to close, then while still holding the button
-move the mouse and the paste happen at the move action.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #4 from Allan  ---
(In reply to Thomas Lübking from comment #2)
> Latter is easily tested: press in an xterm, move over to the problematic
> client and release the button there.
> Is this with the breeze decoration, aurorae or both? (in doubt post output
> of "qdbus org.kde.KWin /KWin supportInformation")

I only tested with Breeze.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

--- Comment #3 from Allan  ---
(In reply to Martin Gräßlin from comment #1)
> That sounds like a bug in the applications. They react on a release although
> they never get a press event. The application should ignore that.
> 
> Do you see this with all applications or just e.g. all Qt applications?

I see it in everything I've tested over so far, including: xterm, konsole
plasma desktop.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362994] middle click to close, in titlebar -passes click to whatever below

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362860] kwin missing setting for wheel event and double click, on the frame

[Allan via KDE Bugzilla]

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

--- Comment #4 from Allan  ---
You don't need to align it with the top of the screen - that is just my typical
use case because then you can just throw the mouse at that infinitely tall
space - makes it easy to hit and use.

In KDE5 unlike in KDE4, you can only scroll/doubleclick at the titlebar, but
not at the titlebar border regardless if you disabled borders entirely, and
regardless where the window is on the screen.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362860] kwin missing setting for wheel event and double click, on the frame

[Allan via KDE Bugzilla]

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

Allan  changed:

   What|Removed |Added

 CC||kdeb...@metalight.dk

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362860] kwin missing setting for wheel event and double click, on the frame

[Allan via KDE Bugzilla]

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

--- Comment #2 from Allan  ---
(In reply to Thomas Lübking from comment #1)
> Which decoration in particular (breeze or some aurorae theme)?
> In doubt attach the output of "qdbus org.kde.KWin /KWin supportInformation".

Breeze is used.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 362860] New: kwin missing setting for wheel event and double click, on the frame

[Allan via KDE Bugzilla]

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

Bug ID: 362860
   Summary: kwin missing setting for wheel event and double click,
on the frame
   Product: kwin
   Version: 5.5.5
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: kdeb...@metalight.dk

Top edge of window need to get wheel and doubleclick events.

- Especially with windows aligned with the top edge of the screen, just
throwing the mouse up there to quickly shade a window with scroll assigned to
shade - is not so quick anymore since you need to move down a bit away from the
frame and into the title area.

This is a regression since kde 4.

Reproducible: Always

Steps to Reproduce:
1. Setup shade on titlebar wheel event
2. Align a window with top screen edge
3. Throw the mouse at the top edge and scroll

Actual Results:  
Nothing happens.
(Same with doubleclick event.)

Expected Results:  
Scroll event set up with titlebar should shade the window.

I even tried a workaround - to set "no frame/border" - in order to make this
useful.. Same depressing result.

Coming from KDE 4: This, and lack of window tabbing; are major regressions.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 362430] KMyMoney crashed on account type change

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
I am able to do this, and then revert it, with no problem, using the
development branch.  4.6.6 is now pretty old, and I would advise that you might
be better off getting 4.7.2, possibly from the Claydoh PPA.

Was this an isolated event, or were you able to reproduce the problem?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 362399] Import of payees details

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
(In reply to Martin Tlustos from comment #0)
> I would like to import my payees details into kmymoney. Manually adding the
> information for several hundred payees is too cumbersome.
> 
> Reproducible: Always

Yes, I can imagine that that would be a bit boring.

>From where do you intend to import (which app)?  It's a long time since I used
Quicken, but if it is relevant, try this - from a Google search
'In Q2012: File > File Export > QIF File. Choose a File to export to. In the
"Include in Export" section, uncheck all but "Category List" and "Memorized
Payees" then 
In Q2013: File > File Import > QIF File. Browse to the QIF file created in
Q2012. Choose any account (or All Accounts) to import into. In the "Include in
import" section, uncheck all but "Category List" and "Memorized Payees". ' 
- to confirm that you can actually export them.  If that works, try to do a QIF
import to KMyMoney.  If that is unsuccessful, could you attach the file to this
bug report, or send off-line to me.  Include the categories - they might be
useful for comparison.

I have, a long time ago, imported a category list, but am not sure about
payees.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #17 from allan  ---
(In reply to NSLW from comment #16)
> (In reply to allan from comment #15)
> > Unfortunately, I am unable to follow the detail of the latest proposed
> > patch, but I would like to urge some caution.  It may be that the proposal
> > does not affect the config file - csvimporterrc, but in its current
> > implementation, it is possible for the user to edit the entries in the file
> > to suit his needs.  If instead the entries are moved into the coding, then
> > recompilation would be required for any changes, which most users would not
> > wish to face.  If this is not the case, then that's fine.
> 
> The second version of the patch is different from the first you've committed
> only in asking m_map for security name using its symbol in uppercase instead
> of lowercase, because m_map is from now on filled by default with symbols in
> uppercase and m_map won't return correct name if asked in lowercase.
> 
> AFAIK no part of csvimporterrc shouldn't impact the behavior changed here.
> In fact we make the behavior lax, so user can in any time change his symbol
> from uppercase to lowercase or mixed case and still get it detected as the
> same symbol.
> 
> If that's fine I think I can apply second version of patch just like you've
> applied the first one.

That sounds good to me.
Would you check on the Frameworks side please, as Christian committed only my
'partial' patch.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)

[allan via KDE Bugzilla]

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

--- Comment #5 from allan  ---
Many/most/some users migrate from Quicken to KMM.  The English terms in
question are exactly the same as those used in Quicken, and probably the MS
equivalent too.

My advice is "Leave well alone."

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)

[allan via KDE Bugzilla]

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

--- Comment #3 from allan  ---
I would not waste my time looking into changing the term 'share' here.  It is
embedded deeply within KMyMoney source code, and appears well over 900 times. 
Bond appears 13 times.

I agree with Jack that possibly instead what is needed is additional guidance
to the translators.

Out of interest, what is the distinction between the original term and the
proposed revision?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #15 from allan  ---
Unfortunately, I am unable to follow the detail of the latest proposed patch,
but I would like to urge some caution.  It may be that the proposal does not
affect the config file - csvimporterrc, but in its current implementation, it
is possible for the user to edit the entries in the file to suit his needs.  If
instead the entries are moved into the coding, then recompilation would be
required for any changes, which most users would not wish to face.  If this is
not the case, then that's fine.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #14 from allan  ---
Very sadly, I find I can not continue my involvement.  Thomas is aware of the
situation.

I think it might be as well for this complete topic to be submitted to
Reviewboard.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361850] Error in German translation

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
One needs to be a little careful in suggesting that a particular translation is
incorrect.  The translated strings get incorporated into the CSV Importer
config file, and it is legitimate for the user to add/delete/amend entries to
match with whatever entries the particular investment institution has decided
to use in its statements.  So, a particular entry might, to one person, seem
incorrect, but to another it actually corresponds with his situation.  So,
alternative versions may be included in the file by the user.
It would be as well for the user to review the entries in his file.

Also, the first item in each of these lines has to match with the standard
transaction types as hard-coded within KMyMoney.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data

[allan via KDE Bugzilla]

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

--- Comment #5 from allan <agande...@gmail.com> ---
(In reply to Ricardo Esdra from comment #4)
> Created attachment 98194 [details]
> attachment-18641-0.html
> 
> I've auto-backup, in megasync cloud, and his update too stayed with 0 kb
> I'll use a old file what I've of february 29, and redoing it until today.
> 
> 
> How I can create a option for auto daily backup?
> exemple [file.kmy_20130401] in the name
> 
> --
> Ricardo Libanio
> 
> 
> 
> 
> 
> ---- Em Sex, 01 Abr 2016 17:19:30 -0300 allan via KDE Bugzilla
> bugzilla_nore...@kde.org escreveu  
> 
> https://bugs.kde.org/show_bug.cgi?id=361271 
>  
> --- Comment #3 from allan agande...@gmail.com --- 
> Just in case there's a hint of help, I don't suppose you could have setup
> for 
> auto-backup? In which case, there might be copies in the same folder as your 
> *.kmy files? 
>  
> Allan

See the KMyMoney handbook -
https://docs.kde.org/stable4/en/extragear-office/kmymoney/firsttime.backup.html.

The information is also in the application - see Help -> KMyMoney handbook ->
Using KMyMoney for the first time -> Backing up.

Plus, see Settings → Configure KMyMoney-> General -> Global -> Autosave...

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data

[allan via KDE Bugzilla]

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

--- Comment #3 from allan  ---
Just in case there's a hint of help, I don't suppose you could have setup for
auto-backup?  In which case, there might be copies in the same folder as your
*.kmy files?

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361191] Reconciled operations won't show up

[allan via KDE Bugzilla]

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

--- Comment #1 from allan  ---
I would advise getting an up-to-date version, first of all.  Look for 4.7.2 in
the Claydoh PPA.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #13 from allan  ---
(In reply to NSLW from comment #12)
> (In reply to allan from comment #11)
> > Are you sure about the change to csvwizard.cpp?  As far as I can see, with 
> > "exists = false;" in the while loop, it works correctly.
> 
> As long as list variable is not empty. If it's empty you wont even enter
> while loop (thus wont even define exists variable) and it is empty if you
> have no securities on "securities tab". It's corner case, I'm sure of.

Yes, of course.  You are right.

I think we're all happy with this now, so I'll be going ahead to commit.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #11 from allan  ---
Are you sure about the change to csvwizard.cpp?  As far as I can see, with 
"exists = false;" in the while loop, it works correctly.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)

[allan via KDE Bugzilla]

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

--- Comment #4 from allan  ---
(In reply to Felix Leimbach from comment #3)
> That's exactly right and is enough to crash kmymoney-4.7.2 as per the "steps
> to reproduce" above. Obviously the real file - a paypal transaction export -
> contains more rows but they are not required to reproduce.

Not for me, I'm afraid.  No crash, no matter what column I select for the date.

Did you completely remove all the remaining rows?

Early on,  I did have problems with Paypal, because of the number of columns,
but I think that should be OK now.

So, I can't go any further at the moment.

> In fact we can narrow it down further: Removing all columns starting with
> and including "Rechnungs-Nr." in the one single line does not stop kmymoney
> from crashing. Remove one more column ("Vorgangs-Nr.") and it does not crash
> anymore.
> It is not the "Vorgangs-Nr." itself though, because renaming that does not
> fix the crash. Also, removing some columns at the beginning can also fix the
> crash.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)

[allan via KDE Bugzilla]

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

--- Comment #2 from allan  ---
I see only a single row, of, apparently, headings, but no actual transaction
data.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

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

--- Comment #8 from allan  ---
(In reply to NSLW from comment #0)
> Buy transactions imported by CSV importer always have missing assignment

It's not correct to say that they '...always have missing assignment'  it is
only under certain conditions.

> (see attachment).
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. file->import csv
> 2. choose investment
> 3. create new profile
> 4. open "test file.csv" and assign columns to values (see attachment)
> 5. FieldDelimiter to comma
> 6. TextDelimiter to double quotes
> 7. DecimalSymbol to comma
> 8. ImportCSV
> 
> Actual Results:  
> In ledger:
> All buy operations have missing assignment
> On home page:
> Balance for banking and investment account are equal.
> 
> Expected Results:  
> In ledger:
> All operations should have assignment
> On home page:
> Balance for banking and investment account should be equal only in special
> cases. Correct difference in balance is shown in attachment.
> 
> To get good balance without the need of patching one has to double click
> every operation in ledger and press enter button. Upon completion column
> value will have exact same values as column from patched KMM.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

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

--- Comment #7 from allan  ---
(In reply to Jack from comment #5)
> Without looking at the details, I believe this is not a problem with the CSV
> importer, but with any KMM import of an investment transaction which
> requires a brokerage account for transfer of funds.

That's not exactly true.  I've just done a QIF import of a Buy transaction, as
a test, and that correctly identified the checking account to be used.

There is also another issue, with fees sometimes getting the wrong sign, which
I identified in https://bugs.kde.org/show_bug.cgi?id=360129.  I think the patch
in this current bug may be related.

>  (I have it with OFX
> import.) The issue is that when KMM imports an investment transaction, it
> does not specify the brokerage account, so the missing assignment refers to
> the amount which would go to that account.  When you edit the transaction,
> KMM automatically enters the brokerage account, so the error disappears.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 361004] CSV Importer doesn't read DecimalSymbol stored in csvimporterrc

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from allan  ---
Well spotted!  Now, why did I do that?

I'll come back to this later.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360938] Scheduled transactions entered in credit card (liability) have random descriptions populated

[allan via KDE Bugzilla]

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

--- Comment #5 from allan  ---
On 26/03/16 15:55, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=360938
>
> --- Comment #4 from lp.allar...@gmail.com ---
> I am not off to a good start.  First I downloaded the sources of 4.7.2 then
> followed the instructions of the README.cmake file which mentions that I 
> should
> run "sudo apt-get build-dep kmymoney" since I am on ubuntu (mint)..  The 
> output
> was
>
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to find a source package for kmymoney
>
> Then I tried to manually start the cmake compilation process and got :
>
> CMake Error at CMakeLists.txt:72 (find_package):
>By not providing "FindQGpgme.cmake" in CMAKE_MODULE_PATH this project has
>asked CMake to find a package configuration file provided by "QGpgme", but
>CMake did not find one.
>
>Could not find a package configuration file provided by "QGpgme" with any
>of the following names:
>
>  QGpgmeConfig.cmake
>  qgpgme-config.cmake
>
>Add the installation prefix of "QGpgme" to CMAKE_PREFIX_PATH or set
>"QGpgme_DIR" to a directory containing one of the above files.  If "QGpgme"
>provides a separate development package or SDK, be sure it has been
>installed.
> -- Configuring incomplete, errors occurred!
>
> I am not sure how to proceed since I am not using KDE as my DE and I am not
> developing apps for KDE..
>

KMyMoney is a KDE application, and to compile from source you would need 
to have a number of dependencies, "QGpgme" included.

However, if you are not familiar with KDE application development, it 
might be better for you to locate the Claydoh PPA, and you should find a 
recent KMyMoney release there.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

--- Comment #9 from allan  ---
(In reply to NSLW from comment #8)
> (In reply to allan from comment #7)
> > I did fix this a while ago, following
> > https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got
> > side-tracked, and it was not committed.
> > 
> > The proposed patch looks, good, but I would make one change, in
> > "
> > securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row,
> > detail)->text().toUpper().trimmed();"
> > 
> > I would propose removing the '.toUpper()', allowing the user's
> > value/preference to be maintained.
> 
> That seems reasonable. Do you need me to send you another patch?

No, thanks.  I think we have enough.

Allan

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

  Attachment #97981|[PATCH] Use parseLine() to  |[PATCH] CSV Importer
description|determine most likely   |detects more columns than
   |fieldDelimiter  |are assigned

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #7 from allan  ---
I did fix this a while ago, following
https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got
side-tracked, and it was not committed.

The proposed patch looks, good, but I would make one change, in
"
securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row,
detail)->text().toUpper().trimmed();"

I would propose removing the '.toUpper()', allowing the user's value/preference
to be maintained.

-- 
You are receiving this mail because:
You are watching all bug changes.