Opened 6 years ago

Last modified 18 months ago

#236 new defect

Cannot advance to next image (Shift-PgDn) when viewing document when multiple plugins handle same type

Reported by: Lewisr Owned by:
Priority: Feedback Pending Milestone: Future
Component: Lucide Core Version: 1.3
Keywords: plugin overlap Cc:

Description (last modified by lewisr)

Shift-PgDn works as expected with all document types I've tested, except JPG, where the same image is simply reloaded. Shift-PgUp *does* work, however, even on these files. (1.3.4b2)

I'm marking this as core, but it's liable to be in the JPG plugin; I don't know the code to make that determination.

PS - Need to add 1.3.4 beta releases to the Version dropdown in Trac.

Change History (9)

comment:1 Changed 6 years ago by diver

  • Milestone set to 1.3.4
  • Owner set to diver
  • Status changed from new to assigned

did that really 100% work with 1.3.3 GA, as we did not touch that code at all.

p.s. the version is still at 1.3, which is ok.

comment:2 Changed 6 years ago by diver

  • Priority changed from minor to Feedback Pending

what OS do you use? Warp4 or ecs? and which exactly?

i can't reproduce it here (tried several installations, but all ecs). and another tester can, but also only one one pc and not on the other.

comment:3 Changed 6 years ago by diver

  • Resolution set to worksforme
  • Status changed from assigned to closed

it seems that the LUGBM plugin is the culprint, as this also loads jpg. wit the standard lucide plugins all works as designed.

comment:4 Changed 6 years ago by herwigb

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Heikos comment on os2.org:

Das Problem liegt anders als in der abschliessenden Note des Tickets beschrieben doch im Core, nicht im Plugin. Ein Plugin hat gar keine Möglichkeit, die Lebenszeit des Dokuments (der Anzeige) zu beeinflussen. Ausserdem existiert dieser Bug schon seit Ewigkeiten, eigentlich seit der ersten Lucide-Version.

Hintergrund des Problems ist, dass sobald mehrere Plugins existieren, die mit denselben Formaten umgehen können (hier JPEG), der Lucide Core irgendwie durcheinander kommt. Dieser Fall scheint nicht vorgesehen zu sein bzw. wird falsch vom Core behandelt. Das Problem lässt sich umgehen, indem lujpeg.dll einfach in lujpeg.dll_ umbenannt wird, wenn lugbm.dll verwendet werden soll (das JPEG ja auch unterstützt). Evtl. sollte ich in der Installationsanleitung für LUGBM einen derartigen Hinweis dokumentieren.

comment:5 Changed 6 years ago by diver

  • Resolution set to wontfix
  • Status changed from reopened to closed

sorry, but i will not enhance lucide at all in this direction. if Heiki thinks it's a Lucide bug, he is free to fix it. we just don't have time to fix problems occur when 2 plugins deal with the same extensions. makes no sense for me anyway.

comment:6 Changed 2 years ago by lewisr

  • Keywords plugin overlap added; advance file next jpg removed
  • Milestone 1.3.4 deleted
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from Cannot advance to next image (Shift-PgDn) when viewing JPG to Cannot advance to next image (Shift-PgDn) when viewing document when multiple plugins handle same type

Reopening, as project is restarting.

This issue continues with 1.3.5 GA. I should have read Heiko's post more carefully (my German is slow, and I have to re-read to get the full context sometimes). the workaround is indeed to rename the lujpeg.dll so that only the lugbm.dll module picks up on the intended file. However, in the event of plugin overlap, Lucide needs to prioritize one plugin over another, perhaps with a preference (or a popup, when the pref hasn't been set).

As we're rebooting the project, hopefully, we'll have a chance to look at this again.

comment:7 Changed 2 years ago by lewisr

  • Owner diver deleted
  • Status changed from reopened to new

comment:8 Changed 19 months ago by lewisr

  • Description modified (diff)

Related: #283

Removing the JPG plugin in favor of GBM would work around this issue for JPG files, but the underlying issue in the core remains that we have no way to specify a preferred plugin for a particular type of document when two or more plugins are loaded which can render the content, nor can we force a particular plugin for a particular file.

I would go one step further and say that if we provide a mechanism to record the plugin preference, we should store that data in Lucide's program directory somewhere or in a user profile directory (as multiple users on the same system may have different preferences - and that's yet another RFE).

comment:9 Changed 18 months ago by gyoung

  • Milestone set to Future
Note: See TracTickets for help on using tickets.