Menu
▾
▴
Re: QT4 GUI
|
From: Michal H. <ms...@gm...> - 2009-08-31 14:55:39
|
On Tue, Aug 25, 2009 at 09:56:24PM +0200, Martin Petricek wrote:
> Michal Hocko wrote:
> > On Thu, Aug 20, 2009 at 02:44:19AM +0200, Martin Petricek wrote:
> >>>> In current code it is src/gui/args.cc
> >>> I don't like this code very much and I don't see any reason keeping it
> >>> in some library. There are many solutions out there which handles
> >>> besically the same thing. Just to mention getopt (POSIX),
> >>> boost-program-options. Why don't we reuse that code?
> >> This code is quite simple, so it was easier to rewrite from scratch than
> >> studying some external library and then trying to reuse it.
> >
> > And now we should do it properly... The smaller code we have the better
> > for understanding it will be.
>
> I looked at boost-program-options and I don't think it is the way to go.
> boost-program-options seems to unite configuration and commandline into
> "one thing", doing a bit more than we need (we already handle configuration
> in different manner, using QSettings from Qt library as backend), and it is
> perhaps too generic (supporting )
And this is very same for every library. It doesn't mean that we want a
one shot solution for our project, though.
>
> Advantages of boost-program-options:
> * the --help page would be probably prettier formatted (but this is fixable
> in current library too :)
> * 6.5 Kb less of code for commandline handling library (args.cc would get out)
>
> Disadvantages:
> * no support for QString -=> need for conversions either to/from std:string
> or wchar_t or alike
Why do we need that?
> * entire commandline handling needs to be rewritten from scratch
> * More complex code (option description component, parser component,
> storage component) -> more code in main.cc
I haven't tried to use it but is this really a case? AFAICS usage in
tools this is pretty straightforward.
>
> Also, the already ported code is Qt4 compatible, working and without any
> known bugs, so I don't think rewrite is necessary - high cost for only
> small benefit.
OK, this is fair but we should focus on making our code as small as
possible. Otherwise we will never attract contributors.
>
> > I am not sure I understand. QApplication parses command line parameters
> > which are intended for QT internal stuff. Automated --help shouldn't be
>
> Yes, QApp parses some parameters, then removes them. So what I get at input
> is commandline with those internal Qt parameters already removed.
>
> > a problem AFAIK. getopt won't be probably a solution here (it was just
> > an example) because it is not available in Windows. boost solution,
> > however, seem to be the right thing to use.
>
> I think rewriting parameter handling should have low priority and it can be
> done later (all parameters are resolved and stored in appropriate variables
> in main.cc, so parameter handling it is quite independent on other code and
> can be easily replaced later).
Close to zero will-be-done-later things have ever been revisited in our
project.
>
> > This was exactly my concern at the very beginning and the reason (the
> > library is not available in any distribution. Keeping it in our code
> > base brings burden of the double maintenance). If you think that this code
> > is really worth including then a separate directory would be best from
> > my POV.
>
> This is what is actually done in qt4 branch and what I intend to do also in
> main branch - keep entire libmpw in separate directory.
> GTK also originally started as some small library inside GIMP codebase.
I am not sure whether this is a good example. I have never worked on
GIMP but I think that everybody was happy when they could get rid of the
library (but maybe I am just mixing it with other project - nevertheless
the tendency is is splitting rather than coupling).
>
> > Though, I am still not persuaded that we need it that much. The decision
> > is up to you, of course, I just want to be sure that you know which
> > problems this comes with and that you have some ideas how to cope with
> > them.
> >
> > Maybe you can try to push the library to some distributions and we can
> > move from in-tree to out-tree linkage later...
>
> Maybe, this can always be done later. GTK was also later separated from
> GIMP ....
>
> >> Well, we can also say "ordering is currently alphabetic, but scripts shold
> >> not rely on it". What about that?
> >
> > No, this is more confusing. If we say that the ordering is not specified
> > then nobody relies on it and script writer thinks more before he makes some
> > assumptions. I would bet that somebody will rely on ordering if he sees
> > that it is working.
>
> Then we can say the ordering is not specified. Also, we have to specify
> what happens, if two (or more) scripts with same name are in various
> startup directories - whether only the first, the last or all of them get
> executed?
Do we want to have more startup scripts? Or you meant system vs. local
ones?
If this is the case I would go for syste first and local after.
> Or report this as bug/warning to PDFedit users and tell them to
> fix their scripts?
>
> first/last: if you accidentally name script with same name as script in
> other startup directory, it won't be run. But it may be used to "replace"
> system startup scripts by putting modified script under same name in
> ~/.pdfedit/....
> all of them: if such script is loaded with include_once as dependency,
> which of them gets loaded? All of them again?
I would go with standard include solution: use the one with relative
path or the system one (in include path) if the previous one doesn't
succeed.
>
> >> predefined functions (like it is now) that load and execute another script
> >> file.
> >
> > OK. Makes sense
>
> Ok, we'll solve dependencies by include_once mechanism.
>
> > This doesn't solve anything. Once you consider alphabetic ordering you
> > have to name scripts properly and this is the reason I don't like the
> > idea. It will be PITA later when we have more scripts. I would stay with
> > dependencies.
>
> If not by alphabetic (or any other) order of running scripts, what
> different way do you suggest for maintaining some consistent order of menu
> and toolbar items added by scripts?
I would just process the directory and don't care about ordering at all.
If someone wants to have consistent ordering in menu, let's do it in one
script.
>
> > No objection even though we should start with reasonably simple solution
> > in the beginning (include and maybe depend).
>
> OK
>
> > How do you handle multiple users of "after everything"?
>
> Same way as multiple users of atexit in C/C++ - these get called in reverse
> order they are registered (from last to first)
Isn't this too much complicated with small value?
>
> >>>> function something() {
> >>>> ... some code ...
> >>>> }
> >>>>
> >>>> if (gui) add_to_menu(something,"main_menu");
> >>>> if (console) register_commandline_function("something",something);
> >>> Do we really need something like this. I think that batch mode is for
> >>> batch operations and it should be as that simple. Why would script
> >>> require some command line callbacks. It sounds overcomplicated.
> >> So assume you have some script for delinearization and some script for
> >> flattenning - how should be (from user's point of view) selected, which
> >> function to invoke and on which files?
> >
> > Script would call delinearize(file) function. What is the problem about
> > that? Why do you need something like register_commandline_function? You
> > would include the delinearizator.qs and use what-ever function you need.
> > Or do I miss something?
>
> You need some way for pdfedit to determine what to call based on
> commandline arguments - so when given "pdfedit -delinearize input.pdf
> output.pdf", pdfedit will know to call delinearize("input.pdf","output.pdf")
Why this has to be different than scripting in the GUI?
>
> Registering will also make sure that "pdfedit
> --list-functions-available-in-console" or alike will list all available
> commandline functions (delinearize flatten, ...)
So we need it?
>
> 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/ |
> \------------------------------------------------------------/
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Pdfedit-devel mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
--
Michal Hocko
|