mudlet-makers team mailing list archive

[Stephen Lyons <slysven@xxxxxxxxxxxxxxx>]

Currently looking in this area of code and your suggestion won't work
with the current code as it is the absence of the real profile directory
that was causing the error and you cannot (currently) delete the
predefined ones!  I think in refactoring/recoding this area I can
provide a solution that does allow deletion (or at least the apparent
deletion) of the predefined ones...

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1378136

Title:
  Broken program logic in dlgConnectionProfiles dialog: assumes profile
  directory exists when this is not guaranteed for "predefined" MUD ones

Status in Mudlet:
  New

Bug description:
  I was noting repeated: "QIODevice::write: device not open" Application
  output messages when using the Connection Profiles Dialog and any of
  the "Predefined MUD" icons were selected that I had never actually
  connected to - this includes the very first one that is the default
  when the dialog is opened.  It transpires that each time a new icon is
  selected the data for the old one is written out to various files that
  would be in the profile directory for that profile e.g. "url", "port",
  "description".  However the Predefined MUDs, if they have never
  actually been used, will not have had a profile directory created for
  them (I suspect but have not confirmed that the directory is created
  at the point when the "Connect" action is initiated) - as a
  consequence Mudlet will try to create the aforesaid files "url" et al.
  in a non-existent directory, this will fail and cause the error
  message seen.

  Note that it would not seem to me to be acceptable to create the
  profile directories that each of the "Predefined" MUD servers would
  need as this would add 15 or so more sub-trees under the
  ~/.config/mudlet/profiles directory.

  The attached diff modifies dlgConnectionProfiles::writeProfileData(
  QString profile, QString item, QString what ) to show the problem but
  I do not know whether by muting the warning output this would be
  enough to solve the issue.  It may be that the logic behind the class
  needs some review...

  I'd suggest this be rated as Medium importance at the minimum.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1378136/+subscriptions