RE: Plucker Channel Addition Automation

[Fringe Ryder]

At 04:20 AM 11/16/2002  +0000, Robert O'Connor wrote:
<snip>

> 3. Creator (if needed) - given a channel name, convert that into the
> appropriate format (e.g. .plkrdata file).  This could be as simple as
> grabbing the relevant fields from the relevant channel section of the INI
> file or it could require packaging of that up to a different format.

Probably not needed. Best just to use a single .ini format (less headaches).

You could have convinced me, if not for you adding the bitmap icon several paragraphs down. How do you figure Joe-User is going to plug a bitmap into an INI file? <grin>

The rundown for operation I guess then would be:
(1) Content provider has link to ".plkrdata" file on their website's HTML page.

(2) User clicks on link, and browser knows to do something with that plkrdata file, to launch
the one-click utility include with an argument of the . .plkrdata file. (Is the part that is
likely the most source of headache, dealing with the different possible browsers to have them
set up right).

Don't most pass the file to the OS if they don't know how to handle it themselves? Popping the type in the registry for Windows and the /proc/sys/fs/binfmt_misc/register for Linux should handle this for most installations, no?

(3) The one-click utililty reads the lines of the .plkrdata file and transfers them to the
plucker.ini. They should probably be sanity checked for at least being proper config format, so
can't bring down the entire parser by a bad file. If using a wxWindows C++, this could be
accomplished by a wxFileConig Read() and Write() to read into the .plkrdata file, but then set
active config to plucker.ini and Write() it there. wxConfig would cough on the way in, so it
wouldn't possibly write illegally formatted stuff to plucker.ini.

I'm a bit leery of dragging in something as big and convoluted as wxWindows solely for ini file processing. The source file (.plkrdata) will have a handful of required fields that can be loaded using a simple GetProfileDataString() or equivalent; if they're missing, spit out an error rather than corrupting Plucker.INI. But I agree that sanity checks are essential.

(3.5) Wesley had suggested to include the large and small icons, which I think is a good idea.
These would be b64 encoded into the .plkrdata textfile. The timing of when to unzip the b64 and
dump the icons into files ready for the parser is up in the air (do it on addition of a new
channel from showcase/.plkrdata, or as part of process before starting a channel, or put into
the parser to handle an icon as a text rendition (similar to how the default icon is in the
sourcecode in Python)?

This is a new one to me. I hadn't even noticed the icon feature until just now, looking through the docs to figure out what you were talking about. The help says that icons must be monochrome; is that still true? Anyhow, popping in the icons requires a bit more data than a standard text INI can handle... need an encoder. Not a problem, but does reinforce the need for a creation function.

(4) If wxWindows C++, can _possibly_ do a quick IPC (Interprocess Communication) using the
wxIPC class (which wraps the native OS's standard IPC mechanism) and if Plucker Desktop is
running, then send a message to Plucker Desktop to reload the main frame's list of My Plucker
Channels. If this step isn't done, I can see new users writing in saying "I added a channel
with 1 click, but it isn't in the list--where is it?". The fallback if no IPC would be a
"Refresh channels" menu command on Plucker Desktop, though that is suboptimal vs. an automatic
refresh when needed. ("Refresh channels" menuitem would also be confusing, since it doesn't
update channels). If IPC too difficult, can drop a key in the [PLUCKER_DESKTOP] to tell to
refresh, and have to check every fixed interval if key=1, and if it is =1, then refresh though
that drains processor power to keep checking. Just doing it on an event, would be better, if
possible.

(5) An inform message tells if added successfully or not (with a checkbox to not show again if
so desired). If wxWindows C++, can recycle that dialog class from the Plucker Desktop source.

(6) Then one-click utility app terminates.

> So questions for the group...
>
> Is this a good idea? Would we use it ourselves? Would it help others?

I think it is a good idea, and would help others. Most of us are developers here, not content
providers. Perhaps the content providers could ring in.

> If so, what subset of INI data should be used and what file format if not
> the INI format?

Support 'em all! ;-)
Might as well give the flexability. It is tough when parts of toolchains drop things.

All?  User?  Image_parser?  Some of these are best not set by a central unit.

Sounds fun though Fringe, if you are up to doing it. As Wesley mentioned, this has been
mentioned before, but needs someone to put it together.

I'll roll it around a bit more to get a better idea of a good shape. As you can tell, despite having gone deep in to wxWindows to fix those issues confounding Desktop, I'm not a fan of it. But I would like the resulting tool to work well with Desktop.

-Tony McNamara-

_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev