Re: gEDA-user: Open GL survey (for PCB)
On Wed, 28 Jan 2009 00:56:05 +, Alexander Gvozdev wrote: Many people want jump-up from ugly GTK. Beauty is in the eye of the beholder. Me, I am all in favor of GTK look and feel. ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GTK RANT
Am Mittwoch, den 28.01.2009, 01:25 +0200 schrieb Robas, Teodor: Shure some people would want standard keyboard accelerators, but IMO this isn't working well even for standard applications. A simple example: krusader (Ctrl+S) vs. eclipse (Ctrl+F or Ctrl+H). And EDA software is anything but standard. A bad result of this standardization wold be Yes. One problem is, that people are used to do thinks in a special way, and they want to do it in this way until they die. If your used tool is a hammer, most task you have to do look like nails. Often I heard: Oh, KDE looks very similar to Windows, so I may consider using it. This looks not like Windows, must be bad. I have to enter a command in as shell -- this is nothing for me. If a great company is behind a new idea, like apple, then these people are more open to new ideas. Driving a motor cycle is different from driving a car... My personal view: gschem and pcb user interface both works not bad. There task is different from web browsers or email programs, so there may a good reason that usage is different. But: A more consistent user interface for pcb and gschem would be nice, i.e. moving of symbols and pcb-elements is a very similar task. If some basic task would be identical in pcb and gschem, this gives a better feeling for new users, and it is no disadvantage for power users. And maybe the visual appearance of both GUIs should have some common parts, so that it is clear for new users that both tools are good friends. Best wishes Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda in Lenny (was Re: Creating system-gafrc again)
On Wed, 2009-01-28 at 23:40 +1100, Hamish Moffatt wrote: Hi, I'm a bit confused about what's needed/expected here. For the lenny release we can only expect to fix RC bugs at this time. This means the copyright/licensing fix, and possibly taking the most critical stuff from 1.4.3 and incorporating it. I can't ask for all of 1.4.3 to be included because we're in freeze and have been since before 1.4.3's release. 1.4.3 only consists of important bug fixes since 1.4.0.. we've been _very_ careful to keep to that so conservative distributions like Debian and Ubuntu would consider it for updates. In order to get any fixes into our 1.4.0 packages we need bug reports against the relevant packages. I don't have any information about what's fixed else I would open relevant bug reports myself. Arguably there are a few commits which are more trivial than others. (Ie. supporting windows file-ends properly) http://geda.seul.org/release/v1.4/1.4.1/gaf-1.4.1-relnotes.html http://geda.seul.org/release/v1.4/1.4.2/gaf-1.4.2-relnotes.html http://geda.seul.org/release/v1.4/1.4.3/gaf-1.4.3-relnotes.html Note that this one: gattrib: Don't special-case ignore components with graphical attribute. is part of avoiding a crash which looses peoples work. If Debian really won't accept 1.4.3, we could export you a series of the most critical fixes, (you'd end up with one or two patches dropped from the 1.4.3 series), but really, I think if you were going to do that, you'd be _much_ better off releasing 1.4.3, since that is a known stable point - which other people and distros are using. If it weren't for the fact that other distros picked 1.4.3 up very quickly, I'd be very cross at the effort we've put into backporting fixes for 1.4.x (done for the benefit of stable distributions), when we could have been putting the effort into 1.6.0. I will upload fixes for the licensing bug tonight. Ok, cool. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Keyboard shorcuts [WAS: Re: GTK RANT]
DJ might just design a keyboard with keys as small as 1005s just to see who could use it. What, you don't like a challenge? Now, a keyboard made with those new OLED keys... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
and C++? NOO! We have enough portability problems as it is. At this point, I don't think C++ would reduce portability. Actually, since C++ is a more standard-requiring language, it might even help. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Wednesday 28 January 2009, DJ Delorie wrote: and C++? NOO! We have enough portability problems as it is. At this point, I don't think C++ would reduce portability. Actually, since C++ is a more standard-requiring language, it might even help. I agree with DJ. These languages are all toolkits. When you have a toolkit, you get to decide what tools to use. One fundamental concept of C++ is what you don't use, you don't pay for. Historically, there have been parts of C++ that not all compilers implemented, leading to perceived portability problems. That's not really a problem any more, but even if it was, just avoid those features. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem usage: rotate symbol, leave text alone
Hi, when working with gschem, I next to never want rotated text. However, by default attributes seem to stick to the graphics and rotate with it. I find myself unrotating the text after I rotated the symbol by 90°. An alternative is to select the graphics only. But this requires many mouse clicks (select symbol, click on each and every attribute while holding the shift key). Is there a way to configure gschem to not rotate or move the attributes while rotating a symbol? ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem usage: rotate symbol, leave text alone
Kai-Martin Knaak wrote: Hi, when working with gschem, I next to never want rotated text. However, by default attributes seem to stick to the graphics and rotate with it. I find myself unrotating the text after I rotated the symbol by 90°. An alternative is to select the graphics only. But this requires many mouse clicks (select symbol, click on each and every attribute while holding the shift key). Is there a way to configure gschem to not rotate or move the attributes while rotating a symbol? Unfortunately most CAD system do that and rotate it all (Eagle does it, too). Kind of a nuisance but often I create two symbols, one rotated and one not. Then I don't have to go through all the mouse clickaroo to unrotate descriptor and refdes. Kind of a duct-tape fix :-) -- Regards, Joerg http://www.analogconsultants.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
Am Tue, 27 Jan 2009 20:51:00 + schrieb Peter Clifton pc...@cam.ac.uk: Hi guys, [... snip ...] glxinfo glxinfo.txt please see attachment [... snip ...] I's also be curious to know what kind of numbers you get running glxgears.. (ok - technically glxgears isn't a good benchmark, but never mind). Default size 39620 frames in 5.0 seconds = 7919.588 FPS Full screen size (22wide 1920 x 1200, 60 Hz) 3997 frames in 5.0 seconds = 799.210 FPS [... snip ...] Kind regards Peter name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_multisample_coverage GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8600 GTS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 180.22 OpenGL extensions: GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_instanced, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_framebuffer_object, GL_ARB_geometry_shader4, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_array_object, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, GL_EXT_bindable_uniform, GL_EXT_depth_bounds_test, GL_EXT_direct_state_access, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, GL_EXTX_framebuffer_mixed_formats, GL_EXT_framebuffer_sRGB, GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_float, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_array, GL_EXT_texture_buffer_object, GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_sRGB, GL_EXT_texture_shared_exponent, GL_EXT_timer_query, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_buffer_float, GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_explicit_multisample, GL_NV_fence, GL_NV_float_buffer, GL_NV_fog_distance,
Re: gEDA-user: gschem usage: rotate symbol, leave text alone
Am Mittwoch, den 28.01.2009, 09:43 -0800 schrieb Joerg: Unfortunately most CAD system do that and rotate it all (Eagle does it, too). Kind of a nuisance but often I create two symbols, one rotated and one not. Then I don't have to go through all the mouse clickaroo to unrotate descriptor and refdes. Kind of a duct-tape fix :-) Similar question, similar answer from me :-) http://archives.seul.org/geda/user/Dec-2008/msg7.html Rotating symbols often makes new alignment of text necessary, so I prefer to have a horizontal and a vertical instance of symbols. It may be nice to have two or more views in one symbol -- horizontal, vertical, with/without pin numbers... But there are more important things to do ... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem usage: rotate symbol, leave text alone
Stefan Salewski wrote: Am Mittwoch, den 28.01.2009, 09:43 -0800 schrieb Joerg: Unfortunately most CAD system do that and rotate it all (Eagle does it, too). Kind of a nuisance but often I create two symbols, one rotated and one not. Then I don't have to go through all the mouse clickaroo to unrotate descriptor and refdes. Kind of a duct-tape fix :-) Similar question, similar answer from me :-) http://archives.seul.org/geda/user/Dec-2008/msg7.html Rotating symbols often makes new alignment of text necessary, so I prefer to have a horizontal and a vertical instance of symbols. It may be nice to have two or more views in one symbol -- horizontal, vertical, with/without pin numbers... But there are more important things to do ... Yes, there are definitely more important things. And even if Peter fixed that then someone would want yet another symbol rendering that makes refdeses glows in the dark and has 3D effects to match Vista ... ducking for cover now -- Regards, Joerg http://www.analogconsultants.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Wednesday 28 January 2009 01:11:08 Peter Clifton wrote: On Wed, 2009-01-28 at 00:56 +, Alexander Gvozdev wrote: I'm maintain pcb for pan-russia/ukrainian/belorussian distro (AltLinux). Many people want jump-up from ugly GTK. Still just as ugly for now ;) I may test pcb on various PC. I develop PCBs with 6-8 layers and think, what OpenGL increace randering speed. Yes, it does.. although it doesn't fix the time we spend computing polygon fills.. which is another common performance problem Give the works so far a try: http://repo.or.cz/w/geda-pcb/pcjc2.git git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout before_pours origin/before_pours (Then build as usual). thanks! The origin/master branch has some other crazy stuff there, like support for pour fills which do island removal by connectivity - and keep any piece culled piece of a poured region which is connected to other entities such as nets, pins etc.. (This allows me to do one copper fill for the whole board, and not worry about having to fill in all the gaps which get culled by PCB's standard keep the largest piece heuristic). Some question: What about migrating to QT3/4 and C++? Nothing stopping someone from writing a GUI in QT (PCB supports multiple front-ends). I don't know anyone keen to do the work. May be I try... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
Peter Clifton wrote: Hi guys, Could anyone interested in seeing / using a GL version of PCB, please respond to this message privately - directly to me (or on-list if you don't have my email address). No OpenGL support for many ATI cards on FreeBSD because no native drivers and the open source ones are mostly lacking support. No idea how good the binary nvidia driver works... So I'm left with software rendering sysctl hw hw.machine: amd64 hw.model: AMD Athlon(tm) 64 Processor 3500+ hw.ncpu: 1 hw.byteorder: 1234 hw.physmem: 2138214400 [...] glxgears 510 frames in 5.0 seconds = 101.838 FPS 508 frames in 5.0 seconds = 101.439 FPS 507 frames in 5.0 seconds = 101.332 FPS grep PCI /var/log/Xorg.0.log (--) PCI:*(0...@1:0:0) ATI Technologies Inc RV670 AGP [Radeon HD 3850] rev 0, Mem @ 0xe000/268435456, 0xfbff/65536, I/O @ 0xe000/256, BIOS @ 0x/65536 [...] xdpyinfo [...] screen #0: print screen:no dimensions:2560x1024 pixels (752x301 millimeters) [...] glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.3 OpenGL shading language version string: 1.10 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATI_fragment_shader, GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_program_debug, GL_MESA_resize_buffers, GL_MESA_texture_array, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square,
Re: gEDA-user: Open GL survey (for PCB)
On Jan 28, 2009, at 2:38 PM, Alexander Gvozdev wrote: On Jan 27, 2009, at 7:56 PM, Alexander Gvozdev wrote: Many people want jump-up from ugly GTK. You have Motif too, and it's possible to write new HIDs for PCB. I know/ I try use he, but he dont look stable :(. Really? I didn't know that. I thought it was being maintained in parallel with the GTK HID. What about migrating to QT3/4 It should be possible to write a QT HID for PCB. and C++? NOO! We have enough portability problems as it is. :) Anyway, i'l try :). If you write a QT HID, I will definitely try it. Please don't suggest moving PCB to C++ though. =) -Dave -- 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: Open GL survey (for PCB)
On Jan 28, 2009, at 11:24 AM, DJ Delorie wrote: and C++? NOO! We have enough portability problems as it is. At this point, I don't think C++ would reduce portability. Actually, since C++ is a more standard-requiring language, it might even help. Theoretically speaking, I agree, but I (like you, I suspect) compile software all the time...and if something is written in C++, that tends to about triple the chances of my having to spend all damn afternoon getting it built. And actually, though, the portability problems that are giving me heartburn lately are with gEDA, not PCB proper. GTK (and its thirty or so dependencies) is a big pain in the ass for anyone who is not running the absolute latest release of Linux on a PC. I am STILL fighting with it, and I've made some progress, though I've given up for now. I managed to get everything built, but now anything GTK- related (including gtk-demo) drops core with something related to threading. That stuff has serious problems. -Dave -- 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: Open GL survey (for PCB)
On Jan 28, 2009, at 11:45 AM, al davis wrote: and C++? NOO! We have enough portability problems as it is. At this point, I don't think C++ would reduce portability. Actually, since C++ is a more standard-requiring language, it might even help. I agree with DJ. These languages are all toolkits. When you have a toolkit, you get to decide what tools to use. One fundamental concept of C++ is what you don't use, you don't pay for. Historically, there have been parts of C++ that not all compilers implemented, leading to perceived portability problems. That's not really a problem any more, but even if it was, just avoid those features. And again, I agree in theory, but in practice things are quite a bit different. A lot of people writing C++ code these days have no idea what they're doing, and the rest of us pay the price in frustration when we try to get something compiled. So, I guess my problem is more with clueless C++ programmers than C++ itself. (though I do consider C++ to be a horribly ugly pile of crap) -Dave -- 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: Open GL survey (for PCB)
On Wed, Jan 28, 2009 at 02:46:16PM -0500, Dave McGuire wrote: If you write a QT HID, I will definitely try it. Please don't suggest moving PCB to C++ though. =) One of these days when I'm bored and looking for a programming project I am going to rewrite it in C++. You could carve a libpcb++ out of PCB and cut the size of the internals by half and probably fix a dozen bugs at the same time (which are only possible now due to rampant code duplication). -- Ben Jackson AD7GD b...@ben.com http://www.ben.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Wednesday 28 January 2009 19:46:16 Dave McGuire wrote: You have Motif too, and it's possible to write new HIDs for PCB. I know/ I try use he, but he dont look stable :(. Really? I didn't know that. I thought it was being maintained in parallel with the GTK HID. GTK HID more stable. From my point of view :) NOO! We have enough portability problems as it is. :) Anyway, i'l try :). If you write a QT HID, I will definitely try it. Please don't suggest moving PCB to C++ though. =) I promise. :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Jan 28, 2009, at 2:54 PM, Ben Jackson wrote: If you write a QT HID, I will definitely try it. Please don't suggest moving PCB to C++ though. =) One of these days when I'm bored and looking for a programming project I am going to rewrite it in C++. You could carve a libpcb++ out of PCB and cut the size of the internals by half and probably fix a dozen bugs at the same time (which are only possible now due to rampant code duplication). You guys really are trying to give me a heart attack today, aren't you. -Dave -- 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: Open GL survey (for PCB)
On Wednesday 28 January 2009 19:54:19 Ben Jackson wrote: On Wed, Jan 28, 2009 at 02:46:16PM -0500, Dave McGuire wrote: If you write a QT HID, I will definitely try it. Please don't suggest moving PCB to C++ though. =) One of these days when I'm bored and looking for a programming project I am going to rewrite it in C++. You could carve a libpcb++ out of PCB and cut the size of the internals by half and probably fix a dozen bugs at the same time (which are only possible now due to rampant code duplication). libpcb++ -- _VERY_ good idea! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
Theoretically speaking, I agree, but I (like you, I suspect) compile software all the time...and if something is written in C++, that tends to about triple the chances of my having to spend all damn afternoon getting it built. I suspect that's a problem with the choice of external libraries, not a problem with the language itself. Also, I don't use STL at all, which avoids some of the old problems. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
A lot of people writing C++ code these days have no idea what they're doing, Yes, that's the key point - C++ makes it easier to do bad things wrt portability, but it's nothing that C doesn't also *allow*. The C programmers have had more experience with portability, that's all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
You have Motif too, and it's possible to write new HIDs for PCB. I know/ I try use he, but he dont look stable :(. Really? I didn't know that. I thought it was being maintained in parallel with the GTK HID. Not in parallel - I maintain the motif (lesstif) HID, Dan (I think) maintains the gtk hid. I use the lesstif hid all the time, it's very stable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Wed, 28 Jan 2009 20:44:12 +0100 Oliver Lehmann lehm...@ans-netz.de wrote: No OpenGL support for many ATI cards on FreeBSD because no native drivers and the open source ones are mostly lacking support. No idea how good the binary nvidia driver works... I have a GeFORCE (was that the right name?) and am using the binary driver. It works fine in normal use - quite fast with video and all. But there may be pitfalls. Eg. if the XFCE compositor is turned on, graphics slow down enormously - video is near impossible then (on a 2.6GHz AMD). John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
I'm not sure if PCB supports UTF-8 text, but if not.. doing that would make a good start. It doesn't. It does support iso-latin-1 but the default font only has ASCII characters in it. Someone would have to draw an eight-bit font. In theory, you could put in whatever eight-bit font you wanted, but that would just be confusing ;-) Metric-only library. (it's imposibble, i know :)) Not _im_possible.. so long as its a very very small metric unit which gets used. It's not practical, either, unless you only have metric parts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Drawing lines in PCB
What would be keeping me from drawing a line in PCB where there's no component? I'm just trying to connect one pin to another. When I click on the end of a line I'll get the ghost line and when I click to place the trace the ghost line (trace) will vanish. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Drawing lines in PCB
Are you drawing on a non-visible layer? Other than that, what you're doing I do all the time - and it always works for me. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Jan 28, 2009, at 3:19 PM, al davis wrote: And again, I agree in theory, but in practice things are quite a bit different. A lot of people writing C++ code these days have no idea what they're doing, and the rest of us pay the price in frustration when we try to get something compiled. A lot of people writing code in any language have no idea what they are doing. Too true. So, I guess my problem is more with clueless C++ programmers than C++ itself. Substitute any other language, that statement is still equally true. True, but not equally true. There are lots of clueless programmers coding in C++ and Java because those are the languages that the programmer mill colleges are teaching these days. That doesn't make the languages bad. I really don't see too many people coding in, say, Lisp or assembler who aren't good programmers. I'm sure you see my point. I still think C++ is syntactically ugly (see below), but that's just my aesthetic opinion. So, can you honestly say that if you were to download, say, ten packages written in C and ten packages written in C++, you'd have as many compilation problems with each? Having likely built as much software as you have, I can loudly say nothing could be further from the truth. I fought with it yet again just yesterday. That's not to say that DJ, Dan, and Ben are (or would be) bad C++ programmers. In fact, I'm quite certain that the exact opposite would be true. But being an open-source project, if it gets rewritten in C++, DJ/Dan/Ben's excellent C++ code would run the risk of becoming polluted by C++ code written by programmer mill idiots who don't know what they're doing. It's an unfortunate line of thought, but we've all seen it happen before, and I like these tools a lot and want to continue to use them. (though I do consider C++ to be a horribly ugly pile of crap) Most of the ugliness is inherited from C, or exists because of the restrictions that come from a goal of making it a proper superset of C. No, the ugliness to which I am referring is the horrible syntax that C++ stapled on top of C. Stroustrup was smoking something very strange when he came up with that. If there were more characters in the ASCII character set, that guy would have come up with more features to tie them to. C's syntax is terse enough as it is, but at least it's a simple language, unlike C++. Can you do better? Show me. I don't mean a theoretically better simple language. I mean something better for the type of jobs C++ was designed for. Oh good heavens. -Dave -- 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: Drawing lines in PCB
Thanks, I didn't click the radio button for that layer. On Wed, Jan 28, 2009 at 3:26 PM, DJ Delorie [1...@delorie.com wrote: Are you drawing on a non-visible layer? Other than that, what you're doing I do all the time - and it always works for me. ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. mailto:geda-user@moria.seul.org 3. 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: Open GL survey (for PCB)
On Jan 28, 2009, at 3:15 PM, DJ Delorie wrote: Theoretically speaking, I agree, but I (like you, I suspect) compile software all the time...and if something is written in C++, that tends to about triple the chances of my having to spend all damn afternoon getting it built. I suspect that's a problem with the choice of external libraries, not a problem with the language itself. Also, I don't use STL at all, which avoids some of the old problems. Well I think it's actually a problem with how the language is most commonly used, more than the language itself, as I waxed poetic on in another message. :) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: OFFTOPIC [WAS: Re: Open GL survey (for PCB)]
Would people please change the subject line of their emails before forking a massively off topic discussion from the original thread. Really, I'm not interested in reading about C++ from non PCB developers, nor having to sort it out from the survey results people are sending. Thanks, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Metric units [Was: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 15:21 -0500, DJ Delorie wrote: Metric-only library. (it's imposibble, i know :)) Not _im_possible.. so long as its a very very small metric unit which gets used. It's not practical, either, unless you only have metric parts. Didn't we come to the view at some point, that using a sufficiently small metric unit internally would work fine? (Due to the definition of 1 = 2.54cm allowing us to precisely specify both metric and imperial units, given a sufficiently small metric unit?) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Text encodings [WAS: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 15:21 -0500, DJ Delorie wrote: I'm not sure if PCB supports UTF-8 text, but if not.. doing that would make a good start. It doesn't. It does support iso-latin-1 but the default font only has ASCII characters in it. Someone would have to draw an eight-bit font. In theory, you could put in whatever eight-bit font you wanted, but that would just be confusing ;-) Indeed.. The rest of the world moved on, to UTF-8 (or other Unicode schemes) I don't want to see any 8 bit text-encoding support added to PCB, _other_ than allowing it to support arbitrary UTF-8 encoded unicode text strings. Right now, we can cheat and pretend we never supported non 7-bit ASCII characters. If we add any support for 8bit code-pages, we'll be stuck having to support those, _and_ UTF-8 in the future. Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Metric units
Didn't we come to the view at some point, that using a sufficiently small metric unit internally would work fine? (Due to the definition of 1 = 2.54cm allowing us to precisely specify both metric and imperial units, given a sufficiently small metric unit?) Changing the internal units of PCB is not practical at this time. I think we calculated we'd need to maintain micrometer precision to preserve the old high resolution units. That means absolutely no more 16-bit coordinate values (oh, darn! ;) and we'd have to be a lot more careful about overflow. Those, however, are technical problems. I did add syntax to the file format to allow you to specify values *with units* so we can at least have metric-based element definitions. They'd still be converte to pcb's inch-based internal units, but perhaps in the future, we can void a lossy conversion. Converting the whole library... no, we'd need to *rebuild* the whole library using native units for each part (mm, mil, etc) would be a huge undertaking. But given that some parts (like SOJ or DIP) are specified in terms of inch units, I think the whole concept of a metric only library is rather pointless. I think what the OP really wants is not what the OP asked for. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Metric units [Was: Re: Open GL survey (for PCB)]
Am Mittwoch, den 28.01.2009, 20:36 + schrieb Peter Clifton: Didn't we come to the view at some point, that using a sufficiently small metric unit internally would work fine? (Due to the definition of 1 = 2.54cm allowing us to precisely specify both metric and imperial units, given a sufficiently small metric unit?) I reported about some problems with mm grid, so I hope I remember the discussion correctly: I think result was that 1nm (nanometre) base-unit should work perfectly. (in my opinion larger units may work good, if rounding is smart.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text encodings [WAS: Re: Open GL survey (for PCB)]
Right now, we can cheat and pretend we never supported non 7-bit ASCII characters. If we add any support for 8bit code-pages, we'll be stuck having to support those, _and_ UTF-8 in the future. Right now we support *uncoded* 8-bit characters and a 256 (er, 255 due to NUL-terminated strings) glyph map. Not quite a font or encoding. Our default font is 7-bit. I agree that UTF-8 will be the *only* expansion option we'll take when we get to that point - but pcb supports iso-latin-1 8-bit at the moment, aside from the missing font issue. I think it would be cool to support freetype, but that would mean expanding the file sytax for text to include font information. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Metric units [Was: Re: Open GL survey (for PCB)]
I think result was that 1nm (nanometre) base-unit should work perfectly. (in my opinion larger units may work good, if rounding is smart.) Er, right - nanometer, not micrometer. That limits board sizes to about 2.1 meters if we want to avoid signed-unsigned problems with 32 bit integers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Metric units
Changing the internal units of PCB is not practical at this time. I think we calculated we'd need to maintain micrometer precision to preserve the old high resolution units. That means absolutely no more 16-bit coordinate values (oh, darn! ;) and we'd have to be a lot more careful about overflow. Those, however, are technical problems. OK, discussion was about 32 bit and nm unit 1e-9*(2**32) = 4.294967296 At least 2m board sizes for signed 32 bit. 16 bit is not enough. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Documentation errors
http://geda.seul.org/wiki/geda:faq-attribs?s=bom I wanted to make a BOM so I cut and pasted the command example, and it did not work. gnetlist -g partlist3 -o output.bom schematic.sch Took a couple of minutes to figure out, but it did not like the partlist3 it should be partslist3 (was missing the s) Can someone fix the web page? Kip -- Kipton Moravec AE5IB Always do right; this will gratify some people and astonish the rest. --Mark Twain ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Documentation errors
Thanks for the bug report. I just updated the wiki page. Stuart On Wed, 28 Jan 2009, Kipton Moravec wrote: http://geda.seul.org/wiki/geda:faq-attribs?s=bom I wanted to make a BOM so I cut and pasted the command example, and it did not work. gnetlist -g partlist3 -o output.bom schematic.sch Took a couple of minutes to figure out, but it did not like the partlist3 it should be partslist3 (was missing the s) Can someone fix the web page? Kip -- Kipton Moravec AE5IB Always do right; this will gratify some people and astonish the rest. --Mark Twain ___ 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: Text encodings [WAS: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 15:51 -0500, DJ Delorie wrote: Our default font is 7-bit. I agree that UTF-8 will be the *only* expansion option we'll take when we get to that point - but pcb supports iso-latin-1 8-bit at the moment, aside from the missing font issue. Its dangerous do document that we support iso-latin-1, lest anyone draws themselves fonts, and then gets cross if we decree in future, that PCB text is in UTF-8. (You could well claim that now.. only we don't understand the 7bit bytes in the encoding!) I think it would be cool to support freetype, but that would mean expanding the file sytax for text to include font information. We could probably embed the glyphs in a similar way to what we do now, but in terms of polygons rather than lines. Granted, you might want to save some idea of what font is being used in the PCB file, so it can be reproduced on multiple machines. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open GL survey (for PCB)
On Wed, 2009-01-28 at 01:11 +, Peter Clifton wrote: Give the works so far a try: http://repo.or.cz/w/geda-pcb/pcjc2.git git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout before_pours origin/before_pours git checkout -b before_pours origin/before_pours ^_ Tells git to create a (local) branch I missed an important flag.. without it, you probably won't succeed in checking out the correct branch, and will end up running various other testing code which is incompatible with how PCB does polygons at the moment. (Then build as usual). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text encodings [WAS: Re: Open GL survey (for PCB)]
- but pcb supports iso-latin-1 8-bit at the moment, aside from the missing font issue. Its dangerous do document that we support iso-latin-1, lest anyone draws themselves fonts, and then gets cross if we decree in future, that PCB text is in UTF-8. Does it do Latin-1, or does it do raw octet streams and you get whatever your font gives you with them (8859-7 if you use an 8859-7 font, for exmaple)? For example, does it know that 1/4 of the possible octet values (00-1f and 80-9f) are not printable characters, or is it willing to put most/all of those into strings and let the chips fall where they may when it comes to display? I consider this an important distinction; I've seen two things already which are, strictly speaking, unimplementable on many Unix variants because they require that OS things be character strings when they actually are octet strings. (What are they? ssh, which specifies UTF-8 for usernames and passwords, and POSIX extended tar header format, which specifies UTF-8 for file names. But on the Unix variants I've worked with, usernames, passwords, and filenames are not character strings; they are octet strings, with conversion to and from characters happening elsewhere if at all.) I'm not sure whether I think switching PCB's philosophy from octet strings to character strings would be a good move. (I think it would be difficult to do, but that's a separate issue.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text encodings [WAS: Re: Open GL survey (for PCB)]
Does it do Latin-1, or does it do raw octet streams and you get whatever your font gives you with them It does raw octet streams with glyph lookups. It doesn't support iso-latin-1 any more than it supports the cursor font, or zapf digbats, or any other 8-bit font. If you *happen* to give it an iso-latin-1 string and *happen* to give it an iso-latin-1 font, you *happen* to get iso-latin-1 support. I'm not sure whether I think switching PCB's philosophy from octet strings to character strings would be a good move. (I think it would be difficult to do, but that's a separate issue.) I think it would make sense if we changed the way we managed fonts. With our current built-in font scheme it doesn't make sense to venture much past 7-bit support anyway. UTF-8 character strings at least can be held in octet strings, stored as such in otherwise-ascii files, etc. That's the benefit of using UTF-8 vs other multibyte encodings. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA portability problems
On Wednesday 28 January 2009 19:51:48 Dave McGuire wrote: And actually, though, the portability problems that are giving me heartburn lately are with gEDA, not PCB proper. GTK (and its thirty or so dependencies) is a big pain in the ass for anyone who is not running the absolute latest release of Linux on a PC. I am STILL fighting with it, and I've made some progress, though I've given up for now. I managed to get everything built, but now anything GTK- related (including gtk-demo) drops core with something related to threading. That stuff has serious problems. gEDA 1.4.x requires GTK+ 2.4 or later. GTK+ 2.4.0 was released on 16 Mar 2004. Claiming (by implication) that gEDA requires the absolute latest release of Linux on a PC is silly. We work *very* hard to fix any portability problems that crop up, and versions of GLib/GTK+ since 2.4 are available for the vast majority of consumer operating systems and CPU architectures. AFAIK, it works on *at least* Solaris, Windows, Linux and BSD, on x86, x86-64, PPC and ARM. The next release of gEDA will require GTK+ 2.8.0, which is much more modern: it was released on 13th Aug 2005. Completely bleeding-edge, I'm sure you'll agree! Rather than just vaguely claiming that gEDA has portability problems, perhaps you could give us some specific details of the platform that you're trying to run it on and the problems that you're having. Peter (Who's going to compile gEDA for Maemo any day now, honest)! -- Peter Brett Electronic Systems Engineer Integral Informatics Ltd signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA portability problems
On Jan 28, 2009, at 5:39 PM, Peter TB Brett wrote: And actually, though, the portability problems that are giving me heartburn lately are with gEDA, not PCB proper. GTK (and its thirty or so dependencies) is a big pain in the ass for anyone who is not running the absolute latest release of Linux on a PC. I am STILL fighting with it, and I've made some progress, though I've given up for now. I managed to get everything built, but now anything GTK- related (including gtk-demo) drops core with something related to threading. That stuff has serious problems. gEDA 1.4.x requires GTK+ 2.4 or later. GTK+ 2.4.0 was released on 16 Mar 2004. Claiming (by implication) that gEDA requires the absolute latest release of Linux on a PC is silly. Well. Admittedly, that was typed out of frustration. And, also admittedly, I'm talking about the git head, not 1.4.x. We work *very* hard to fix any portability problems that crop up, Absolutely, and I've been consistently impressed. I certainly wasn't bashing gEDA; I talk it up to anyone who will listen...and even a few people who won't. ;) and versions of GLib/GTK+ since 2.4 are available for the vast majority of consumer operating systems and CPU architectures. AFAIK, it works on *at least* Solaris, Windows, Linux and BSD, on x86, x86-64, PPC and ARM. Not Solaris, at least not right now. The next release of gEDA will require GTK+ 2.8.0, which is much more modern: it was released on 13th Aug 2005. Completely bleeding-edge, I'm sure you'll agree! Rather than just vaguely claiming that gEDA has portability problems, perhaps you could give us some specific details of the platform that you're trying to run it on and the problems that you're having. Remember the big saga of me trying to get the latest git code running under Solaris? As I mentioned earlier, I've given up for the time being because I had some other stuff I had to deal with, but I'm going to start working on it again shortly. (Who's going to compile gEDA for Maemo any day now, honest)! Now THAT would be fun! I keep an old N700 on my night stand that I use for early morning email reading. It'd be neat to edit schematics on that. ;) -Dave -- 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: gEDA portability problems
On Wednesday 28 January 2009 22:56:09 Dave McGuire wrote: and versions of GLib/GTK+ since 2.4 are available for the vast majority of consumer operating systems and CPU architectures. AFAIK, it works on *at least* Solaris, Windows, Linux and BSD, on x86, x86-64, PPC and ARM. Not Solaris, at least not right now. Please try the latest GTK+ 2.8.x point release, and see if that works. It has a lot less code than the very newest GTK+ release, so it should have fewer portability problems. I'm confused: I thought OpenSolaris used a GTK+-based GUI? Peter -- Peter Brett Electronic Systems Engineer Integral Informatics Ltd signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA portability problems
On Jan 28, 2009, at 6:06 PM, Peter TB Brett wrote: and versions of GLib/GTK+ since 2.4 are available for the vast majority of consumer operating systems and CPU architectures. AFAIK, it works on *at least* Solaris, Windows, Linux and BSD, on x86, x86-64, PPC and ARM. Not Solaris, at least not right now. Please try the latest GTK+ 2.8.x point release, and see if that works. It has a lot less code than the very newest GTK+ release, so it should have fewer portability problems. I will; thank you for the suggestion! I'm confused: I thought OpenSolaris used a GTK+-based GUI? It does. (well, more like can) Thing is, the stuff it ships with is kinda old, too old for later release of Cairo to use. So...The resulting deluge of dependencies had me compiling crap for days. -Dave -- 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: gEDA portability problems
On Wed, 2009-01-28 at 18:11 -0500, Dave McGuire wrote: Please try the latest GTK+ 2.8.x point release, and see if that works. It has a lot less code than the very newest GTK+ release, so it should have fewer portability problems. I will; thank you for the suggestion! I'm confused: I thought OpenSolaris used a GTK+-based GUI? It does. (well, more like can) Thing is, the stuff it ships with is kinda old, too old for later release of Cairo to use. So...The resulting deluge of dependencies had me compiling crap for days. I'd still suggest going for the latest GTK and cairo versions. Last time we were looking at this, I got the feeling that the problems you're encountering were not portability problems per-se, rather that you ended up with gEDA linked against various libraries, which might themselves have been built against different versions of other dependencies. If you end up with geda linking liba and libb, where liba and libb both depend on libc, you can certainly expect segfaults if liba and libb were built against different versions of libc. Add the entire dependency chain into the mix, and it doesn't take much to make something unstable. If you're finding problems with threading, perhaps some of the libraries gEDA ended up linking against were compiled with different options in that regard. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA portability problems
On Jan 28, 2009, at 6:14 PM, Peter Clifton wrote: I'm confused: I thought OpenSolaris used a GTK+-based GUI? It does. (well, more like can) Thing is, the stuff it ships with is kinda old, too old for later release of Cairo to use. So...The resulting deluge of dependencies had me compiling crap for days. I'd still suggest going for the latest GTK and cairo versions. Last time we were looking at this, I got the feeling that the problems you're encountering were not portability problems per-se, rather that you ended up with gEDA linked against various libraries, which might themselves have been built against different versions of other dependencies. I did have exactly those problems. I spent most of an afternoon digging through all of that, though, and I'm confident that I've gotten them resolved. The latest GTK (and friends) are compiled and installed, but anything that uses them dies with a bus error (even gtk-demo) which I've not been able to track down. I've forgotten the details (a busy two weeks have gone by since then) but it was something to do with threading. Oh, and also, just to be clear...I'm running production Solaris 10, not OpenSolaris. -Dave -- 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: gEDA portability problems
On Wed, 2009-01-28 at 18:19 -0500, Dave McGuire wrote: I did have exactly those problems. I spent most of an afternoon digging through all of that, though, and I'm confident that I've gotten them resolved. The latest GTK (and friends) are compiled and installed, but anything that uses them dies with a bus error (even gtk-demo) which I've not been able to track down. I've forgotten the details (a busy two weeks have gone by since then) but it was something to do with threading. Oh, and also, just to be clear...I'm running production Solaris 10, not OpenSolaris. How about compilers.. (used for each library). Someone on #geda suggested that there are compatibility problems between sun studio and gcc. GLib might be the root of your threading problems.. any idea if its using the pthread or thread library? Does glib's test-suite pass? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 22:13 +, Peter Clifton wrote: On Wed, 2009-01-28 at 01:11 +, Peter Clifton wrote: Give the works so far a try: http://repo.or.cz/w/geda-pcb/pcjc2.git git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout before_pours origin/before_pours git checkout -b before_pours origin/before_pours ^_ Tells git to create a (local) branch [snip] (Then build as usual). Since the latest code pushed (which has begun a slight refactoring), you need to call configure with --enable-gl for it to look for and link against the required OpenGL libraries and GtkGLExt. NB: If you don't pass --enable-gl, the build fails.. I didn't yet get to the point where the GL code in the GTK HID is conditionally compiled in. At the moment, its more a GL fork of the GTK HID. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]
Peter Clifton wrote: On Wed, 2009-01-28 at 22:13 +, Peter Clifton wrote: On Wed, 2009-01-28 at 01:11 +, Peter Clifton wrote: Give the works so far a try: http://repo.or.cz/w/geda-pcb/pcjc2.git git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout before_pours origin/before_pours git checkout -b before_pours origin/before_pours ^_ Tells git to create a (local) branch [snip] (Then build as usual). Since the latest code pushed (which has begun a slight refactoring), you need to call configure with --enable-gl for it to look for and link against the required OpenGL libraries and GtkGLExt. NB: If you don't pass --enable-gl, the build fails.. I didn't yet get to the point where the GL code in the GTK HID is conditionally compiled in. At the moment, its more a GL fork of the GTK HID. without looking at the code, is it feasible without major pain to have GL be a runtime selection? Here's why I ask. I *routinely* run the same binary on the same computer but with drastically different displays. On one day I might be at the computer running the program and have access to the modern display hardware that gave 1300 FPS for that glxgears demo but then I might use vnc to connect to that same machine later and have not GLX support. Should I expect a speed improvement with GLX or just cool stuff like layer transparency? I suspect that's a feature that won't take much use before I say how did I live without this?. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: new symbols
Peter Clifton wrote: On Tue, 2009-01-27 at 21:17 +0100, Oliver Lehmann wrote: Stefan Salewski wrote: My one, shipped with gEDA 1.4.3 is tragesym version 0.0.12 and dist-license and use-license is supported. FreeBSD ports come with geda 20070216 which is probably a svn/cvs/whatever ;) checkout. And yeah - sounds old Dan: Is this really the latest gEDA in BSD? each BSD maintains its own packaging system. Looks like I'm behind because NetBSD is at 1.4.0. I'll get that updated. I have no idea what version FreeBSD is on. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 19:59 -0500, Dan McMahill wrote: without looking at the code, is it feasible without major pain to have GL be a runtime selection? I was thinking I'd split out the HID vtable callbacks into GTK / GL versions, and #ifdef the HID setup. Since the HID vtable can (I think) modified at run-time, I don't see why we couldn't swap the rendering functions. The main difficulty would be ensuring that the GC state for both the GDK and GL drawing are kept set up. GDK / X11 needs GC setting up. GL needs fbconfigs / GLXVisuals selecting. We'd of course need to make having failed picking up the correct GLX visual non-fatal. Here's why I ask. I *routinely* run the same binary on the same computer but with drastically different displays. On one day I might be at the computer running the program and have access to the modern display hardware that gave 1300 FPS for that glxgears demo but then I might use vnc to connect to that same machine later and have not GLX support. I tried it from my laptop (albeit on a fast university network), remote X11 forwarded. I had to force the GL library to pick an indirect rendering mode (sends commands via the wire to the X server, rather than talking to the hardware), but I was _amazed_ at how fast it ran. It wasn't noticeably slower than on my local PC. (Same for gschem, including vicious dragging of entire schematics). The only parts which were slow.. were the GTK dialogs. (Testing gschem on a different computer via X11 gave really poor panning performance though.. I guess it might have been falling back on some of the cairo rendering (possibly via the network, right to the client app). Should I expect a speed improvement with GLX or just cool stuff like layer transparency? I suspect that's a feature that won't take much use before I say how did I live without this?. It is faster, and transparent ;) Ok.. I got the feeling it wasn't as snappy (dare I say slower?) than GDK rendering for small designs, but for big complex stuff, you're looking at say, 2-3fps - 20fps speed change (plucking some vaguely remembered numbers out of my head). DJ tested it, and IIRC got similar speed-ups over Lesstif. Go on.. take it for a test-drive, you know you want to ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]
On Wednesday 28 January 2009 09:27:28 pm Peter Clifton wrote: On Wed, 2009-01-28 at 19:59 -0500, Dan McMahill wrote: Should I expect a speed improvement with GLX or just cool stuff like layer transparency? I suspect that's a feature that won't take much use before I say how did I live without this?. Oh, you are so right. I started using it about six hours ago and if it doesn't get merged back in then you can consider me forked. It is faster, and transparent ;) And completely addictive... DO NOT open any of your old boards with this, you will waste too much time just making them look better. Go on.. take it for a test-drive, you know you want to ;) Yeah, once you get on that ride you ain't never going back. :) -Mark Stanley ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Any discussion about combining schematics and symbols into one file?
We have garchive in utilities, it should suffice. i don't know it's current status, but i though it's purpose was to make an archive of a project so that it could be remade or shared easily across many folks Hardkrash On Jan 27, 2009, at 2:40 PM, Stefan Salewski wrote: Am Montag, den 26.01.2009, 21:27 -0500 schrieb Bob Paddock: a collections of files is much harder to maintain than a single file, when you want to easily share the design, or maintain it for many years. Similar discussion in scientific/university work: Some people want to have all stuff in one file -- one single word document with pictures ... Other like multiple files, text in LaTeX source, measuring data in text- or binary files, gnuplot scripts to plot data, graphics in postscript or pdf. I am not which is better. ___ 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: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]
On Wed, 2009-01-28 at 23:53 +, Peter Clifton wrote: Give the works so far a try: http://repo.or.cz/w/geda-pcb/pcjc2.git git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout before_pours origin/before_pours git checkout -b before_pours origin/before_pours ^_ Tells git to create a (local) branch [snip] (Then build as usual). Since the latest code pushed (which has begun a slight refactoring), you need to call configure with --enable-gl for it to look for and link against the required OpenGL libraries and GtkGLExt. NB: If you don't pass --enable-gl, the build fails.. I didn't yet get to the point where the GL code in the GTK HID is conditionally compiled in. At the moment, its more a GL fork of the GTK HID. Cautionary note: Beware of accidentally relying on a anti-polygon behaviour I was playing with, which is still in the before_pours branch. Pressing j over a polygon turns it into an anti-polygon, which clears away other polygons. (It doesn't work with the electrical connectivity check though, which may catch you out, and the whole idea might never make it into any official PCB release!) (The original idea was that islands might be removed as a batch operation by inserting computed anti-polygons). If you fancy playing with some other experimental polygon stuff though (again, not yet backwards compatible), try the master branch which does full real-time island removal. The broken pieces of pour are actually now separate polygons internally, so work correctly for electrical connectivity checking. This allows (for example) one big rectangle fill to work on a board, but allows islanded sections of the fill either to be removed, or be re-connected (not necessarily to the same net), in order that they are kept. I've still not figured out how to make this work in a backwards compatible way. It much more closely matches PCB's _old_ semantics before Harry introduced computational polygon support. That change broke backwards compatibility with old layouts (which assumed all pieces of polygon were kept) - I don't want to break anyone's designs again! Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Strange error from gEDA upon startup
Has anybody see this error where the icons at the top of the window can't be found? Attached is the error window. System is Max OSX 10.5.6 Thanks, Fred Kingston Co. fred...@sb.net Error msg.pdf Description: Adobe PDF document ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
