gEDA-user: Using GOptionContext to parse command line arguments
Dear friends,
I have modified gschem.c to use command line arguments from
GOptionContext. I did not find the version control repository from
gEDA, so I have used the source from the Ubuntu deb for version 1.6.1 as
a base. Instead of sending a patch, I will hereafter enumerate the
changes.
I. When including:
#include glib/gi18n.h
to define _() and N_()
II. Just before main_prog, tell which are the command line arguments and
respective variables.
static const gchar **remaining_files =
NULL;
/*! The command line options recognized by the application, to
be added to those of GTK+.
*/
static const GOptionEntry cmdline_options[] =
{
{ quiet, 'q', 0, G_OPTION_ARG_NONE,
quiet_mode,
N_(Quiet mode),
NULL },
{ verbose, 'v', 0, G_OPTION_ARG_NONE,
verbose_mode,
N_(Verbose_mode),
NULL },
{ auto-place, 'p', 0, G_OPTION_ARG_NONE,
auto_place_mode,
N_(Automatically place window),
NULL },
{ stroke-info, 't', 0, G_OPTION_ARG_NONE,
stroke_info_mode,
N_(Print stroke information),
NULL },
{ rc, 'r', 0, G_OPTION_ARG_FILENAME,
rc_filename,
N_(RC file name),
N_(filename) },
{ script, 's', 0, G_OPTION_ARG_FILENAME,
rc_filename,
N_(Script (guile) file name),
N_(filename) },
{ output, 'o', 0, G_OPTION_ARG_FILENAME,
rc_filename,
N_(Output filename (for printing)),
N_(filename) },
{ G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_FILENAME_ARRAY,
remaining_files,
N_(The files to open.),
N_([files...]) },
{ NULL }
};
We have all the command line options pot in the globals.c Now, the
remaining files to open are writen in the variable remaining_files.
We either pass in no file, and then remaining_files is NULL, or it is
a NULL terminated array of strings.
III. Finally, main_prog. There are quite a few changes. We have to
declare a GError and a GOptionContext first (if it was only for GCC...).
We replace gtk_main and parse_cmdline with GOptionContext creation,
parsing and error handling. Finally, we open the files in
remaining_files without the need anymore of argv_index.
I have not compiled the code, because I cannot compile in this machine,
but I have used the same code in various other applications, and I
actually copied, pasted and adapted from one of my applications. Please
tell me if it fits your purposes.
I enclose the whole file, as main_prog is quite large.
Sorry for the trouble, but I think that being the first time I actually
have a look at the code, and not being the latest version control code,
a patch could
Re: gEDA-user: Draft Licence for Open Source Hardware published
On Wed, Jul 14, 2010 at 4:48 PM, Stefan Salewski m...@ssalewski.de wrote: See http://www.h-online.com/open/news/item/Draft-Licence-for-Open-Source-Hardware-published-1038048.html commentary here: http://www.bunniestudios.com/blog/?p=1224 -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published
[snip] See http://www.h-online.com/open/news/item/Draft-Licence-for-Open-Source-Hardwar e-published-1038048.html commentary here: http://www.bunniestudios.com/blog/?p=1224 And my usual questions: http://lwn.net/Articles/396011/ -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
I think that the proper place to resolve this issue is in the actual *licenses,* which as with OSS may vary from permissive to restrictive. I'd like to see the evolution of at least one OSHW license where a requirement is that the design files for the project-- and its derivative works --need to be in open, documented formats. Keep dreaming, bro. Maybe when gEDA reaches 1/10th the functionality/usability of say Protel. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
On 7/14/10 10:51 PM, timecop wrote: I think that the proper place to resolve this issue is in the actual *licenses,* which as with OSS may vary from permissive to restrictive. I'd like to see the evolution of at least one OSHW license where a requirement is that the design files for the project-- and its derivative works --need to be in open, documented formats. Keep dreaming, bro. Maybe when gEDA reaches 1/10th the functionality/usability of say Protel. Damn, and here I was hoping he had unsubscribed. Go design a circuit or something, if you can. Use Protel, so maybe you'll get something done, huh? -Dave ...most decidedly having a zero asshole tolerance day -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
I think that the proper place to resolve this issue is in the actual *licenses,* which as with OSS may vary from permissive to restrictive. I'd like to see the evolution of at least one OSHW license where a requirement is that the design files for the project-- and its derivative works --need to be in open, documented formats. Keep dreaming, bro. Maybe when gEDA reaches 1/10th the functionality/usability of say Protel. You can have an open documented format for a proprietary EDA tool. I don't see what gEDA has to do with anything in that comment. And you don't have to be a dreamer to write a license that has whatever terms you want in it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
On Jul 14, 2010, at 7:54 PM, Dave McGuire wrote: On 7/14/10 10:51 PM, timecop wrote: I think that the proper place to resolve this issue is in the actual *licenses,* which as with OSS may vary from permissive to restrictive. I'd like to see the evolution of at least one OSHW license where a requirement is that the design files for the project-- and its derivative works --need to be in open, documented formats. Keep dreaming, bro. Maybe when gEDA reaches 1/10th the functionality/usability of say Protel. While it's nice to know that your full-of-yourselfness extends to gEDA, it's not the only game in town, and it's not even the only open source EDA with open file formats. This will happen whether or not gEDA evolves, and whether or not gEDA is involved. Damn, and here I was hoping he had unsubscribed. +1 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Hi everybody
Hi, i'm from Venezuela, my english is very poor (sorry). I'm new on this list, in gEDA and even in electronics. I want to learn gEDA and i think, in the way i can translate some documentation into spanish. I use Debian (stable) and if you could guide me what is the right way to begin the translation of the doc, please tell me. Thank you. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
On Jul 14, 2010, at 7:46 PM, Windell H. Oskay wrote: On Jul 14, 2010, at 7:36 PM, Ales Hvezda wrote: And my usual questions: http://lwn.net/Articles/396011/ I've had some part in this. Whether or not proprietary design files can be compatible with open source hardware has been an active topic of debate, even amongst the people writing that draft definition. It's a tough, tough call, for all the reasons that Bunnie mentions. I think that the proper place to resolve this issue is in the actual *licenses,* which as with OSS may vary from permissive to restrictive. I'd like to see the evolution of at least one OSHW license where a requirement is that the design files for the project-- and its derivative works --need to be in open, documented formats. That's the right answer -- let there be a battle of licenses. Although hopefully, it is a small set and we avoid the license salad issues that have sprung up in software. I, too, want to see (and would use) a license where all source files for all aspects of the design are in open, documented formats, but that isn't going to be to everyone's liking or practical in all cases. But also, I'd like to point out that just having an open documented source language isn't really enough. What I really want in the end is a 100% open source tool chain, and simply having an open file format isn't sufficient. Example: FPGA's. Verilog source isn't going to help if the FPGA fitter tool proprietary. So (thinking out loud) maybe some kind of license that says the file format documentation *and* sources (or mirror pointers) for all the development tools are a required part of the distribution source. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
Example: FPGA's. Verilog source isn't going to help if the FPGA fitter tool proprietary OK. Please name a vendor for FPGA hardware + toolchain that fits into this absolutely ridiculous requirement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
On Jul 14, 2010, at 9:47 PM, timecop wrote: Example: FPGA's. Verilog source isn't going to help if the FPGA fitter tool proprietary OK. Please name a vendor for FPGA hardware + toolchain that fits into this absolutely ridiculous requirement. I don't understand your question. Can you clarify? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Draft Licence for Open Source Hardware published (OT)
You said you wanted a 100% open source tool chain and gave FPGA as example. So, please name a vendor who provides such hardware/software (for FPGA design) which would satisfy this license requirement of being 100% open. On Thu, Jul 15, 2010 at 2:06 PM, Dave N6NZ n...@arrl.net wrote: On Jul 14, 2010, at 9:47 PM, timecop wrote: Example: FPGA's. Verilog source isn't going to help if the FPGA fitter tool proprietary OK. Please name a vendor for FPGA hardware + toolchain that fits into this absolutely ridiculous requirement. I don't understand your question. Can you clarify? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
