Re: Plucker Desktop initial tour
On Thu, Nov 15, 2001, Robert O'Connor wrote: Did some minor things too: This is your baby, so you can commit whatever changes you think are necessary ;-) I will probably make a few suggestions here and there (and make sure that it continues to work on Linux), but right now I should concentrate on the VFS support, Handera support, and the Linux version of the viewer. Only parse out the basename if it was a doc_file/db_file, so that don't lose part of the channel name if have a dir character or period in a proper doc_name key (I think that Mac separator is a ':' ). Is a doc_name really proper if it has such characters in the name? BTW, I don't see any problems in adding the plucker-desktop code to the main trunk (maybe in the tools dir?), so maybe you should just go ahead and do that. Will make it easier for others to access the code (just get the snapshot from the web site.) /Mike
Re: Plucker Desktop initial tour
On Tue, Nov 13, 2001, Robert O'Connor wrote: Please feel free to add these to cvs whenever you so wish. Added. Please try it out to make sure that it still works OK on Windows. BTW, it might be a good idea to change the get_configuration_extension() to instead return the *filename* for the config file. /Mike
RE: Plucker Desktop initial tour
Hi Michael,
Added. Please try it out to make sure that it still works OK on Windows.
All looks good!
I did need to modify basename() [function doesn't seem to exist in the gcc
cygnus] to the wx equivalent path splitting function to get the doc_names to
load properly (-u diff is below).
Did some minor things too:
Always link and thumbonly reused in write configuration to keep them in
sync.
Only parse out the basename if it was a doc_file/db_file, so that don't lose
part of the channel name if have a dir character or period in a proper
doc_name key (I think that Mac separator is a ':' ).
A variable (foundSection) moved to lowercase (found_section).
Some comments as to why looking for db_ keys are (looking a ways down the
line, in case people are wondering what they are or why they are there).
BTW, it might be a good idea to change the get_configuration_extension()
to instead return the *filename* for the config file.
This makes good sense.
Here is the patch:
--- main_dialog.cpp 14 Nov 2001 19:05:11 - 1.1.2.5
+++ main_dialog.cpp 15 Nov 2001 00:35:11 -
@@ -71,7 +71,7 @@
// Easier code maintenance if want to add/rearrangement of listctrl's
columns.
// SECTION_COLUMN needs to be 0 in current code as GetNextItem only seems
to look at
// the zero column.
-#define SECTION_COLUMN0 // Listctrol column: Directory stored in
+#define SECTION_COLUMN 0 // Listctrol column: Directory stored
in
#define NAME_COLUMN 1 // Listctrl column: Channel's name
#define DUE_COLUMN 2 // Listctrl column: When due
@@ -196,7 +196,7 @@
wxString configuration_section; // Section of channel in
configuration file
int row_number = 0; // List row to insert channel
information
long index = 0; // Index counter for looping through
the sections
-bool foundSection= FALSE; // To monitor success of getting
first/next group
+bool found_section = FALSE; // To monitor success of getting
first/next group
wxFile file; // To make a home.html if missing.
wxLogDebug( Starting to load channel sections into listctrl rows );
@@ -210,9 +210,9 @@
// TODO: also make the default channel one, in case in is gone.
-foundSection = the_configuration-GetFirstGroup( configuration_section,
+found_section =
he_configuration-GetFirstGroup( configuration_section,
index );
-while ( foundSection ) {
+while ( found_section ) {
// Load up the each channel section (group) from the
// plucker.ini/pluckerrc file
wxLogDebug( Configuration section is %s,
@@ -221,21 +221,26 @@
// TODO: check for illegal characters (spaces, etc) in the
// section name, and rename the section in the config file
// as necessary before loading it into listctrl.
-
+
wxString doc_name;
doc_name = configuration_section + /doc_name;
-
+
+// If no doc_name key, then use the db_name key
+// The db_name key is the depreciated equivalent of doc_name
key
if ( ! the_configuration-Exists( doc_name ) )
doc_name = configuration_section + /db_name;
-
-if ( ! the_configuration-Exists( doc_name ) )
+
+// If no db_name key either, the the doc_file key as the
doc_name also
+if ( ! the_configuration-Exists( doc_name ) )
doc_name = configuration_section + /doc_file;
-
-if ( ! the_configuration-Exists( doc_name ) )
+
+// The no db_name or doc_file key, then use the db_file key.
+// The db_file key is the depreciated equivalent of doc_file
key
+if ( ! the_configuration-Exists( doc_name ) )
doc_name = configuration_section + /db_file;
-
-// only include channels with an assigned document name
+
+// Only include channels with an assigned document name
if ( the_configuration-Exists( doc_name ) ) {
wxString channel_name;
wxString due_date;
@@ -250,9 +255,13 @@
// row. TODO: The 0 in 3rd argument of InsertItem put
// as the image index for a little glyph later on.
channel_name = the_configuration-Read( doc_name,
-_T( Unnamed
Channel) );
-
-channel_name = basename( channel_name.c_str() );
+_T( Unnamed
Channel ) );
+// If it was a filename key, then strip off path and the
+// extension, so only basename left
+if ( doc_name == configuration_section + /doc_file ||
+ doc_name == configuration_section + /db_file ) {
+wxSplitPath( channel_name.c_str(), NULL, channel_name,
NULL );
+}
RE: Plucker Desktop initial tour
It crash if the exclusionlist.txt file is empty. You are right. Nice catch! Will have to certainly error catch here. Perhaps ask them where the exclusion list is would probably be ideal, or if would just like a new one. Best wishes, Robert
Re: Plucker Desktop initial tour
On Tue, Nov 13, 2001, Michael Nordström wrote: --- configuration.cpp 12 Nov 2001 18:22:20 - 1.1.2.4 +++ configuration.cpp 13 Nov 2001 18:03:06 - +#ifdef __WXGTK__ +string = plucker + get_configuration_extension(); +the_configuration = new wxFileConfig( string ); +#elif __WIN95__ string = wxGetCwd() '/' plucker get_configuration_extension(); the_configuration = new wxFileConfig( Plucker Desktop, The Plucker Team, string, wxEmptyString, wxCONFIG_USE_LOCAL_FILE ); +#endif This is just a quick hack to get it running. I guess it should be possible to create only one common configuration for all platforms. /Mike
Re: Plucker Desktop initial tour
On Tue, Nov 13, 2001, Michael Nordström wrote: When I was about to create a screenshot of the exclusion list it crashed. It crash if the exclusionlist.txt file is empty. Seems like the wxString type can't handle NULL assignments. A check to see if the file is empty before traversing it should fix the problem. Also, exclusionlists can be included in any section, so it is not enough to just check e.g. POSIX on Linux. Another thing is that on POSIX systems we use ':' to separate the list of exclusionlists. /Mike
RE: Plucker Desktop initial tour
I did an implementation of sections, but there is probably better ways of doing it. The changes you did cover most of the stuff I had done to support sections, so that is more or less OK also on Linux. I had to make some minor adjustments, though (see diff below). All good stuff! Please feel free to add these to cvs whenever you so wish. I'm going spend the next while to pick up a Mac laptop and do a compile/runthrough for that too. I think the last figure I read was 10% of Palm buyers were Mac. More important for myself though is their prevelence in medicine (since in the past were better at both medical imaging and some custom hardware integration technologies). BTW, I would really recommend that you drop all these anonymous variable names and use proper names. Names like 'string', 'lng' and 'i' don't tell you anything about their use. Names like 'doc_name', 'bpp', and 'category' do ;-) Sure thing. For the source end of things, certainly aiming for something that can be instantly examined by anyone of the plucker team and users and see immediately what is going on, without having to sift through to have to back track or understand the program as a whole. Just for curiosity, would it be possible to post a screenshot of what your copy looks like on your computer, so it is easier to get an idea of what things look like? When I was about to create a screenshot of the exclusion list it crashed. Some problem in listctrl_load_rows. I will take a look at it. I have put a few screenshots of other dialogs at http://www.sslug.dk/~micke/plucker/desktop/ Cool! These look great. Best wishes, Robert
RE: Plucker Desktop initial tour
Sections would definately be an easier way to deal with configurations (for not the least of which, it would absolve of having to keep switching and creating/destroying config objects). I can send you a diff with the changes I had to do to make it work with sections instead of different config files. Not that many changes. Maybe you can find something useful in it. Yes please. By all means. I did an implementation of sections, but there is probably better ways of doing it. I was wondering about where to best save a channels's home.html, Many channels will not have a home.html file, i.e. they will just include a URL to the contents. Others will have a local html file, but not necessarily a home.html file that is part of Plucker. Currently they are generated, (didn't read your message until today). :) Perhaps a create-on-demand would be okay, so the unwashed masses don't have have to think about creating this lower-level item, but if the home.html isn't ever used, it is never created. And/or a checkbox in advanced tab of main dialog to turn off generation if so desired? I was debating also on whether to ever ask the unwashed masses for a section name, or to just generate it from the channel name (sans spaces and illegal characters), and provide a button (showing a popup dialog) at the top of the channel dialog to change the section if they so desire, as the parameter to store settings is more of a lower-level thing, and is more of a nitty-gritty how is this action being executed rather than answering a what do I want to do. Also, farther down the road, a channels cache directory will probably raise in importance as the stuff in it will likely be examined and reused. If the user wants to create a local file with links using the desktop tool's HTML editor then it could be stored in ~/.plucker (or a subdir) given a unique name instead of having a lot of home.html files in different directories. There is sort of alot of things already in ~/.plucker, so might get a bit stifling to start dropping in random html files into the root directory. If specifying a spot for it (as a subdir) it seems more extensible to make it a place to tie its cache directory along with it too, plus leaving the door open to whatever channel-specific files are needed in the future (eg a channel's cookie file, or something like that). While caches and cookie files and icon.bmps can be all over the place in the user's hard drive, it seems easier to have a logical default pattern for them to follow to keep things tidy, while they are becoming comfortable with the new program. From the user standpoint though I reckon most won't care one way or the other as long as things work out of the box without alot of hassle. Some gaps were filled in yesterday and today (the exclusion dialog I think looks quite pretty), also put in the image handling for inserting hyperlinks and a rewrite to section configs as you suggested, plus some other stuff to get ready to put to main cvs to see if there are some kind folks out there who want to roll up their sleeves. I think we are turning the half-way point as far as getting the core-functionality, and its starting to take good shape. Just for curiosity, would it be possible to post a screenshot of what your copy looks like on your computer, so it is easier to get an idea of what things look like? Best wishes, Robert
Re: Plucker Desktop initial tour
On Mon, Nov 12, 2001, Robert O'Connor wrote: Yes please. By all means. I did an implementation of sections, but there is probably better ways of doing it. I will take a look at your latest changes before I create a diff. Maybe you can add the blocked_dialog files to CVS, too ;-) Just for curiosity, would it be possible to post a screenshot of what your copy looks like on your computer, so it is easier to get an idea of what things look like? Tomorrow... /Mike
RE: Plucker Desktop initial tour
I will take a look at your latest changes before I create a diff. Maybe you can add the blocked_dialog files to CVS, too ;-) Doh! Thanks for catching this. Added straight away. Just for curiosity, would it be possible to post a screenshot of what your copy looks like on your computer, so it is easier to get an idea of what things look like? Tomorrow... Sounds great. Here is a picture of what the widgets look like here: http://www.rob.md/projects/plucker/2001_11_12/plucker_desktop.gif I'll try to pick up a Mac laptop off the faculty, and do a run on there too. Best wishes, Robert
Re: Plucker Desktop initial tour
On Sun, Nov 11, 2001, Robert O'Connor wrote: Is there separate home.html's? You can specify any html file as your home.html file by using the home_url key in the section. If no home_url is given the default is to use home.html in PLUCKERDIR. How are the sections identified in the ~/.pluckerrc file? The same way all sections are identified, i.e. [SECTION NAME]. Don't forget that DEFAULT, POSIX, OS2 and WINDOWS are also sections (in wxWindows they are called groups) At the moment, I only include sections with a home_url key in my list of channels, e.g. in my pluckerrc file I use both standalone sections and support sections and the latter doesn't make sense in a list of channels. Example: [dilbert] bpp = 4 home_url = file:/var/spool/netcomics/index.html alt_maxwidth = 600 alt_maxheight = 200 doc_file = Daily/Dilbert before_command = pluck-comics -d -h dilbert [sunday] bpp = 2 maxwidth = 500 maxheight = 500 doc_file = Daily/SundayComics Then I can run plucker-build -s dilbert to create a Plucker document and on Sunday (when the comics strip is too large for the default format) I run plucker-build -s dilbert -s sunday to get a Plucker document with less bit depth but with a better scale factor for the larger image. The sunday section can be used together with other sections, too. My view of the config file is to consider the DEFAULT section to include global options and then all the real work is put into the individual sections. /Mike
Re: Plucker Desktop initial tour
On Sun, Nov 11, 2001, Robert O'Connor wrote: What would you recommend for these and also alt_width and alt_height? What is a good value for this from efficient compression/time point of view? 999 and , respectively? That is, unlimited ;-) Most normal users will use the default values, while power users want some extra freedom... Okay. For moving verbosity from advanced shared settings to channels specific, where would you think it would fit best? On second thoughts, leave it as it is. Probably makes more sense to keep it as a global option in a tool like this. A few file dialogs were wired up just a trial to see how they look. They look very Windows-like ;-) Certainly. Anything particular in mind? Not really sure what to call it, since I think many of the options belong in the Output options tab. just for building things that will never go on to the users device, like a e-book that is to sent out/published somewhere. Sure, I don't think the Send to directory should be removed, only that it shouldn't be the only option for Linux users. What I would like is an option to specify that the created Plucker documents should be installed on the device *after* all of them have been created -- don't want to create one, install it, create next, install it, ... ;-) Another (long-term) feature that would be cool is for the Install Handheld Software dialog to have an option to get the latest versions from www.plkr.org. BTW, at the moment the Set default configuration for new channels button always opens the last used channel. I guess that will be replaced with a default channel. Actually, I think there should always be a Default channel in the list (that can't be removed) which includes all the default settings (i.e. the settings you find in the DEFAULT section in the config file.) /Mike
Re: Plucker Desktop initial tour
On Sun, Nov 11, 2001, Robert O'Connor wrote: Glad to hear that could compile okay! I have fixed a couple of bugs in the latest changes to the source code that prevented it from compiling on Linux (and also on Mac if someone has tried that.) I also added a makefile for Linux/Unix. /Mike
RE: Plucker Desktop initial tour
Then I can run plucker-build -s dilbert to create a Plucker document and on Sunday (when the comics strip is too large for the default format) I run plucker-build -s dilbert -s sunday to get a Plucker document with less bit depth but with a better scale factor for the larger image. The sunday section can be used together with other sections, too. Aha I see, that was the critical bit--I never paid attention to the -s option in the plucker-build list of things. Nice. At the moment, I only include sections with a home_url key in my list of channels, e.g. in my pluckerrc file I use both standalone sections and support sections and the latter doesn't make sense in a list of channels. That makes good sense, and is a good strategy. My view of the config file is to consider the DEFAULT section to include global options and then all the real work is put into the individual sections. Definately, I agree. Sections would definately be an easier way to deal with configurations (for not the least of which, it would absolve of having to keep switching and creating/destroying config objects). Also faster on the loading of rows into main dialog's list control and easier to execute with a button execute command. I was wondering about where to best save a channels's home.html, in a GUI context of having a HTML editable file of a list of links, but which you want to abstract this concept away from them? Also, farther down the road, a channels cache directory will probably raise in importance as the stuff in it will likely be examined and reused. Still worthwhile to have channel directories to hold these two items (but not the channel's config file)? Best wishes, Robert
Re: Plucker Desktop initial tour
On Sun, Nov 11, 2001, Robert O'Connor wrote: Sections would definately be an easier way to deal with configurations (for not the least of which, it would absolve of having to keep switching and creating/destroying config objects). I can send you a diff with the changes I had to do to make it work with sections instead of different config files. Not that many changes. Maybe you can find something useful in it. I was wondering about where to best save a channels's home.html, Many channels will not have a home.html file, i.e. they will just include a URL to the contents. Others will have a local html file, but not necessarily a home.html file that is part of Plucker. Also, farther down the road, a channels cache directory will probably raise in importance as the stuff in it will likely be examined and reused. Still worthwhile to have channel directories to hold these two items (but not the channel's config file)? In Linux I don't see any use of a channels directory that can't be handled by the current PLUCKERDIR directory (default: ~/.plucker). That is, if the user wants to create a local file with links using the desktop tool's HTML editor then it could be stored in ~/.plucker (or a subdir) given a unique name instead of having a lot of home.html files in different directories. /Mike
RE: Plucker Desktop initial tour
Some more comments (some of them points out items that would need to be changed for the Unix and Linux platforms), - it's unnecessary to include an option to turn on/off the compression, since it doesn't make sense to not use at least DOC compression (if the compressed data will be bigger than the uncompressed data the uncompressed data will be included by default) Definately makes sense. Checkmark removed, and replaced a choice control. The choice text also has in brackets behind it that ZLIB is recommended. - the max width and height pixels are too low (i.e. the max value is the default value -- you probably want to be able to set it higher) What would you recommend for these and also alt_width and alt_height? - the max compress images limit is also too low What is a good value for this from efficient compression/time point of view? - should include some info that the option to display an icon in the launcher really is an option to make the Plucker document launchable (and that this only works on newer versions of Palm OS) I was looking at that myself and certainly agree that could be better worded. - might be a good idea to have all items selected by default in the Install Handheld Software dialog I agree. These will be put in programatically though, so that if they deselect the manual, it will stay off. Ditto for language, device, etc on that dialog. - it would be nice if it was possible to set different verbosity for the channels Okay. For moving verbosity from advanced shared settings to channels specific, where would you think it would fit best? - missing option to set the image parser (we have several in the Unix/ Linux version:) Definately. There is a helper_dialog in the resource file, but not coded in yet. - might be a good idea to be able to set image options in the hyperlink dialog Sounds very reasonable. - is it possible to lock the invisible column (used to store the directory in the Windows version -- I use it to store the section name), so that you can't make it visible? Interesting. There doesn't seem to be any Enable or Show/Hide functions that I've noticed. Possibly one of the EVT_LIST events is called when the column is resized and could then set the column width back to zero. Items that are useless on a Unix/Linux system (or have to be modified to be useful): - Launch Plucker into taskbar... There is an os tag that can be used in the XML resource to comment out controls that have no meaning on other systems, so that can use the same resource file across them all and still have the things that fit in with the os as a whole. A nice idea--the guy was on the ball that day. - *.exe to identify programs in the File dialog Definately. I was considering pulling out all the filedialog calls into a util so that they can be easier to manage. A few file dialogs were wired up just a trial to see how they look. - the Sync to tab should be given a different name in the Linux version, since it will have nothing to do with hotsync Certainly. Anything particular in mind? - Send to Sync username and Install to have to be changed for the Linux version -- no sync user name and some of us rather install it on the device than sending it to a directory ;-) Syncing on Mac and Windows should be pretty much the same, but Linux will have its own method. Directory is there not only for a make sure that it works option for someone starting a fresh install of Plucker, but also for just for building things that will never go on to the users device, like a e-book that is to sent out/published somewhere. From a UI point of view, what fits this best on Linux? ( ) Install to handheld device ( ) Send to directory Best wishes, Robert
Plucker Desktop initial tour
The Plucker Desktop can now be taken for an initial tour. Can download the zip and run it. This is a Windows32 binary compile. Linux and Mac haven't been compiled yet, but should only need minor if any improvements to the codebase. http://www.rob.md/projects/plucker/2001_11_05/plucker_desktop.zip This is a debug build (zip is 1.1MB), having all the wxWindows debugging stuff in it, plus some more debug messages of my own (hook in a message listener to watch the normal execution messages go by as the program runs). Some things are currently wired up, including: -the XML resources. -loading up and moving around the dialogs. -main dialog: loading up details into main forms listcontrol. -HTML editor dialog: can add a plucker hyperlink using the wizard button. -main dialog: if select one of the rows in listcontrol, then press configure (or double click the list control's row), will load up that config file (currently just the name at the top of the dialog) for editing, and can save change to name with 'OK'. ToDo: a refresh of the row in listcontrol when finished. -channel dialog: loading/saving a test html file in HTML editor dialog and flipping to the preview tab to see the result. -channel dialog: gallery button will call up a gallery. A sample custom parser parses a regular SGML text file and loads up the example channels into the list control ready to click and enter. -main dialog: config load/saves of most main form control entries to an ini file. MJ's idea to have a box for a command to execute after plucking has been included (also a box for command before plucking). Also takes up David's idea and is structured as 2 parts: a plucker-desktop and a plucker-daemon. Comments (good or bad) are welcomed. Best wishes, Robert
