Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-help-dev] Re: [platform-doc-dev] new help system proposal

Hi all:

Disclaimer: I'm a help author, not an engineer, and am probably missing something when trying to understand the need and implementation of this proposed help feature for OS-specific information.

Following along with the discussion, it seems that someone has a desire to package platform-specific help graphics separately, perhaps to reduce the install image size for each platform. It sounds like a neat idea and there are possibly other benefits, too, I'm not sure.

But when looking at the agreed upon implementation, with its similarity to the NL way of organizing things, it raised a question in my mind.

konradk@xxxxxxxxxx wrote:
> Enhancing help system to search paths under os specific locations like:
> os/linux/x86/doc.zip!file,
> os/linux/doc.zip!file,
> nl/zh/CN/doc.zip!file,
> nl/zh/doc.zip!file,
> doc.zip!file,
> os/linux/x86/file,
> os/linux/file,
> nls/zh/CN/file,
> nl/zh/file,
> file solves the problem. Windows screen capture can be packaged in doc.zip of a
> plug-in as done today, and Linux fragment can be later added with os/linux/doc.zip
> containing a Linux equivalent image.

So, if I understand it correctly, if the help system wants an OS-specific graphic, it goes to a an OS-specific directory to get it, and if it doesn't find it, goes to the NL directory, then to the default doc directory.

But, what if the help system needs a graphic that is _both_ OS and NL specific? For example, what if a user has a need to see a screen capture of an AIX system with Chinese text? In which doc.zip would the help author put such a file? If I put it in the os/aix/doc.zip, then how do I differentiate the language? And if I put it in nl/zh/CN/doc.zip, then how is the OS differentiated?

----
I'm assuming the proposed new feature is suggesting separate folders. That is, either:

com.mycompany.doc.nl1
com.mycompany.doc.os1

or...

com.mycompany.doc/nl/cn/zh
com.mycompany.doc/os/aix

It seems that in order to handle the case that I brought up, some multiplicative or inclusive tree structure is needed. For example,

com.mycompany.doc/nl/zh/CN/os/aix
com.mycompany.doc/os/aix/nl/zh/CN

or

com.mycompany.doc.nl1/zh/CN/os/aix
com.mycompany.doc.os1/aix/zh/CN

But, if this is true, then where do you stop? The plugin directory structure could expand to umpteen factors if it's decided that things need to be divided even further, such as by UI or Windowing system (KDE, Gnome, Motif, ...) or user experience (expert/novice).

In such a scenario where there are many factors, Eclipse would have to include a Cloudscape or MySQL plugin just to manage the attributes and decide which help topics to present. ;-) The CSS idea could work (or even an XSLT-dynamically transformed XML topics, if it were possible). Although you wouldn't get the nice cascading default that Konrad suggests.

-g-


Back to the top