From: Martin P. <ma...@pe...> - 2009-08-18 16:14:38
|
>> We need it, because it is basically large part of original PDFedit already >> ported to QT4 >> (menu, toolbars, > > I assume that you mean configurable menu and toolbars, right? Yes. >> commandline parameters handling > > We have only few parameters and we don't have to depend on some library > because of them. They need to be reworked anyway (we have to cleanup the > way how we call scripts for batch mode) No, it is system for options - it will examine argc/argv and resolve all options and then pass only the rest (the parameters) to the main program (or script, depending how the pdfedit is invoked). It also handles checking parameters for correctness (if you specify invalid one, you get error like "Invalid commandline option: --hchkrdtn") and printing help. In current code it is src/gui/args.cc >>> What is the maintenance cost and what are advantages from using it? >> Advantage: finished and tested QT4 code doing things we need. Originally, >> it was forked from pdfedit because I needed configurable toolbars, menus >> and such for my program in my thesis. That is when it was ported to Qt4, as >> the program was Qt4 only (though now it is no longer developed). Later I >> reused it in my MPView project (image viewer) and I improved and cleaned up >> the code. It is clean Qt4 code, it does not use any qt3 compatibility >> classes from Q3support. >> I have some long term plans for some features (like keyboard shortcuts >> reconfigurable in GUI), so once these ae done, both PDFedit and MPView can >> benefit from it. > > OK, I see. How big is the code at the moment? 22 .cc files, 23 .h files, 144 Kb of code You can check the source - download MPView and see at "libmpw" subdirectory http://sourceforge.net/projects/mpview/files/mpview/0.4.3/mpview-0.4.3.tar.gz/download >> Maintenance cost is close to none - improvements from one project can be >> just copied to other, the only thing is which the directories with the >> library differ is the .pro file, because in MPView the configuration is >> slightly different, so there are different compile options. Rest of the >> code is identical. > > How you want to maintain this library in two different revision control > systems? Where is the main repository? Where do you plan to track bugs? Both are CVS, so simply fix it in one project, commit, copy it to other, commit. Bugs will be tracked where they'll be spotted and once fixed, changes will propagate to the other project. >>>> What ordering do you suggest? Alphabetical ordering have advantage, that >>>> while you usually don't know what gets started before/after/inbetween your >>>> scripts, you can guarantee that your scripts will be started in some order. >>>> Better that starting in some completely random order. >>> If they don't have any dependencies - which they shouldn't have anyway - >>> then the ordering is irrelevant, right? >>> Are you aware of any dependencies? >> No. But as we can't run them in parallel (that would require >> multithreading), we have to run them in some order. it is IMHO better to >> have well defined order than to run then in some "random" order because: >> >> * Well defined and repeatable behavior -> fewer bugs that would occur only >> sometimes when some scripts are run in "incorrect" order. > > If there are no dependencies then this shouldn't by an issue. No, but if there is some bug that occur only when some scripts run in certain order (possibly some conflict where once script declares a function/variable and second one redeclares it), having fixed order would help to reproduce the bugs. >> * Some scripts appends item to menu/toolbar. Running the scripts in same >> order mean items are always appended in same order. > > Yes, this is a valid point. Are there any other scripts, besides those > for GUI configuration, which might depend on ordering? > >> * Usually there are no dependencies between individual scripts, but if >> there would be need for any, they can be solved this way. > > How would we handle dependencies? Is there any way to incorporate them > into scripts? (e.g. // depends: menu) Scripts can include each other - we can add some "include_once" mechanism, that will load the script only if it was not already loaded by one of the scripts before. So scripts will just specify at their start: include_once("dependency1"); include_once("dependency2"); include_once("dependency3"); Perhaps we can also specify that using include_once on autostart script that is not yet executed will execute it and then remove it from the startup queue (technically, we will call include_once on all startup scripts). This could change the order to satisfy dependencies. For softer dependencies (if script X is present run it before this one), we can add include_once_if_exist("script.qs") >> * Sometimes it may be just convenient to run scripts in specific order >> (creation of menu items, etc ...) > > Please note that I am not opposing alphabetic ordering in principle, I > would just like to prevent from bad decision from the very beginning. > Alphabetic ordering is not a bad solution but it brings some maintenance > burden - just look at System V init and how hard is to add new services > (especially when you are not distributor). You usually end up with S99 > for all of you scripts. > > If we need to have some dependencies then the naming startup convention > is not very suitable (the more scripts the harder to find the proper > place for them). Scrips should be pretty independent on each other, though this could be used to maintain relative order with scripts from single author, like having script like extension_main.qs and extension_optional.qs, the second being run alway after (but perhaps not directly after) the first one, helping to maintain some logical order. Though there would probably be some scripts that want to run "after everything else" (perhaps something that browses through all menus and does something with them?) and these would probably get named like zzzz_something.qs But dependencies should be solved by "include_once" and not by ordering. > AFAIU we want to have startup scripts for GUI configuration, right? Or > does it make sense to have some also for batch mode? Yes, batch mode need it too - the batch mode startup script will look at commandline parameters and then decide what other script function to call on what files. >>>> Maybe we should stick with current model - one init script and then >>>> directory with "plugins" (GUI/console) - extension scripts, technically >>>> directory with scripts that are all run at start. >>> Then we should have autorun and scripts directories. The first one for >>> automatically started scripts and the second for convenient scripts >>> (core functionality). >>> Example: >>> autorun/delinearizator.qs - dialog for file opening >>> scripts/delinearizator.qs - core implementation of delinearization so >>> that it can be used from other scripts as well >> That would be good - the "scripts" directory could be in "include path", so >> path won't need to be specified. > > exactly > >> The question is - do we need to run some (system) script before (and maybe >> also after) running all the autorun scripts? Currently we have init.qs that >> is run before any autorun scripts... > > I think that we need autorun scripts only for GUI configuration, but > maybe I am missing something. For console too - GUI scripts adds items to menu to call other functions in them, console scripts register callbacks for certain comamndline parameters. One script can contain both, like function something() { ... some code ... } if (gui) add_to_menu(something,"main_menu"); if (console) register_commandline_function("something",something); >>>> What do you consider "bare minimum"? >>> Everything for proper application start without any extensions. You >>> would be able to open a document and do some basic editing. >> I think default icon theme can be put into resources (if you want to change >> icons, you can easily set up new theme, any missing icons in the theme gets >> replaced by default ones), but I'd hesitate to put there scripts or global >> configuration, as system admin may want to edit it (perhaps to install some >> global improvements or library) Translations can't be put into resources, >> but these are only optional. > > OK. I think that scripts should be a part of binary as well. If we look > at the current directory then this shouldn't matter (we would be able to > run also without installation). Or, maybe, we could add a parameter > where to look for scripts if someone wants to run from special > environment. This parameter is already part of global pdfeditrc. If someone would need to disable the internal scripts and use only external, he can just remove resource://scripts (or something like that) directory from the script search path, so scripts could be put inside >> Anyway, it is easy to decide (and change if needed) later what to put into >> resources and what not. > > OK. This sounds reasonable. Could be even configurable using --configure if needed - embed nothing/reasonable defaults (scripts, default icon theme)/everything (could be useful to create "portable executables" to run from USB sticks, etc ...) Martin Petricek -- GPG/PGP Public key: http://www.petricek.net/petricm.pgp Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8 /------------------------------------------------------------\ | WWW: http://www.petricek.net/ | \------------------------------------------------------------/ |