Re: [Ekiga-devel-list] HEAD has issues...
On Mon, 11 Sep 2006 07:42:49 +0200 Julien PUYDT [EMAIL PROTECTED] wrote: ..deleted Here is what the current code does: a) If PWLIBPLUGINDIR is set, set the plugin search path to this value and go to step d) b) Get the directory containing the executable and put that into the plugin search path This is bad on non-win32. It's both good and not good. It's very useful for deployment - it means that you can have a single directory with the application and all of the plugins with no extra work required. It's bad because sometimes the local directory contains other stuff including lots of subdirectories. While writing this, I'm thinking that perhaps searching the local directory without recursion might be a good idea. I'm not sure there is a single good answer here. c) Append the value of P_DEFAULT_PLUGIN_DIR to the search path This appending looks wrong. What part looks wrong? d) Assume the plugin search path is a list of directories and search each directory recursively. The differences between Unix and Windows are: - The seperator between path elements is : on Unix and ; on Windows DIR_SEP is nice to handle that. Not sure what you mean here. DIR_SEP (as a macro) is defined and used in pluginmgr.cxx - The default value for P_DEFAULT_PLUGIN_DIR is C:\PWLIB_PLUGINS on Windows and .:/usr/lib/pwlib: on Unix The easiest way to search a user-specific search path for plugins is to ask the user to set the PWLIBPLUGINDIR variable to $(HOME)/pwlib_plugins. However, I guess we can add parsing to this code so that we can specify ~/pwlib_plugins or some such, where ~ corresponds to the users home directory. The easiest for us. Most users are unable to set an environment variable. And remember that on unix, setting PWLIBPLUGINDIR in a shell, makes it available only in that shell! We should check if freedesktop.org has a specification for such things (it has one for configuration options), as it's probably the sanest thing to use on unix-like systems. I'm open to implementing a standard if it makes sense and the code is not too difficult. I agree that removing . from the default plugin path for Unix is probably a good idea as users often run programs in a directories that have large sub-trees. It was removed from the Windows default value for that very reason. Then I would say : let's remove it from cvs right now, as a quick fix to the issue, while we get to think about a sane replacement for that scheme. The plugin search code has been used for the last year or so for all plugins (including the audio and video devices) on both OPAL and OpenH323. I'm not sure why this has suddenly become an issue that needs an immediate patch I'd like to know what has changed before I start modifying existing code to fix problems You mentioned writing new code for plugin searching (which seemed to have something to do with the H.263 plugin) ; could you be more specific? The H.263 plugin codec is a straight port of the old embedded H.263 codec. This code loaded the file libavcodec.so at runtime to get access to the ffmpeg functions. The plugin does the same thing, because I didn't want want to embed the ffmpeg code into the plugin. When the codec was part of OPAL, it used the same plugin loader code as PWLib and so it searched the same path. Now that the plugin is seperate code, it needs to implement the same search mechanism internally. Craig --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] It takes a man to suffer ignorance and smile. Be yourself, no matter what they say. Sting ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] HEAD has issues...
Damien Sandras a écrit : Le lundi 11 septembre 2006 à 16:05 +1000, Craig Southeren a écrit : The plugin search code has been used for the last year or so for all plugins (including the audio and video devices) on both OPAL and OpenH323. I'm not sure why this has suddenly become an issue that needs an immediate patch We start having many bug reports, suddenly : http://bugzilla.gnome.org/show_bug.cgi?id=355358 From : http://openh323.cvs.sourceforge.net/openh323/pwlib/src/ptlib/common/pluginmgr.cxx?r1=1.30r2=1.31 I gather it was broken : Wed Jul 19 05:37:39 2006 UTC (7 weeks, 5 days ago) and we didn't detect it at that time because we were not tracking HEAD with ekiga's HEAD. So this is a new issue, and it can have a fast fix by just removing .: from the non-win32 P_DEFAULT_PLUGIN_DIR. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] URI ComboBoxEntry
Hi, is there any chance of being able to replace the current (=CVS) GtkComboBoxEntry with a GtkEntry + GtkEntryCompletion combination? This would make it a lot easier to put a padlock icon in there because there are already various implementations floating around (e.g. ephy-icon-entry.c is very simple and can be reused easily, libsexy has a GtkIconEntry and Gtk 2.12 may also get one). Thanks, Daniel ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] URI ComboBoxEntry
Hi, The GtkComboBoxEntry already uses a GtkEntryCompletion. Removing it would be a regression as you wouldn't have any more the list of last dialed numbers. Le lundi 11 septembre 2006 à 15:01 +0200, Daniel Smertnig a écrit : Hi, is there any chance of being able to replace the current (=CVS) GtkComboBoxEntry with a GtkEntry + GtkEntryCompletion combination? This would make it a lot easier to put a padlock icon in there because there are already various implementations floating around (e.g. ephy-icon-entry.c is very simple and can be reused easily, libsexy has a GtkIconEntry and Gtk 2.12 may also get one). Thanks, Daniel ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] URI ComboBoxEntry
On 9/11/06, Jan Schampera [EMAIL PROTECTED] wrote:
While you were writing the last few mails I dug into that stuff. If
you already have working code, can you share it?
The patch is attached (although I developed it against a version which
is a few days old and rebased it to CVS HEAD, it should work).
ephy-icon-entry.h/c does the hard part of the icon entry and is copied
verbatim from the Epiphany browser source.
The lines enclosed by TEST TEST TEST add a icon to demonstrate that
it actually works, though probably the final version will/should have
a GmURIEntry derived from EphyIconEntry which handles the nasty stuff
of setting up the actual icons and provide functions like
gm_uri_entry_set_security_status() for Ekiga to call.
--
Daniel
=== added file 'lib/gui/ephy-icon-entry.c'
--- lib/gui/ephy-icon-entry.c 1970-01-01 00:00:00 +
+++ lib/gui/ephy-icon-entry.c 2006-09-11 13:59:08 +
@@ -0,0 +1,352 @@
+/*
+ * Copyright (C) 2003, 2004, 2005 Christian Persch
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ * Adapted and modified from gtk+ code:
+ *
+ * Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
+ * Modified by the GTK+ Team and others 1997-2005. See the AUTHORS
+ * file in the gtk+ distribution for a list of people on the GTK+ Team.
+ * See the ChangeLog in the gtk+ distribution files for a list of changes.
+ * These files are distributed with GTK+ at ftp://ftp.gtk.org/pub/gtk/.
+ *
+ * $Id: ephy-icon-entry.c,v 1.4 2005/08/07 20:31:32 chpe Exp $
+ */
+
+#include config.h
+
+#include ephy-icon-entry.h
+
+#include gtk/gtkentry.h
+#include gtk/gtkbox.h
+#include gtk/gtkhbox.h
+
+#define EPHY_ICON_ENTRY_GET_PRIVATE(object)(G_TYPE_INSTANCE_GET_PRIVATE ((object), EPHY_TYPE_ICON_ENTRY, EphyIconEntryPrivate))
+
+struct _EphyIconEntryPrivate
+{
+ GtkWidget *hbox;
+};
+
+static GtkWidgetClass *parent_class = NULL;
+
+/* private helper functions */
+
+static gboolean
+entry_focus_change_cb (GtkWidget *widget,
+ GdkEventFocus *event,
+ GtkWidget *entry)
+{
+ gtk_widget_queue_draw (entry);
+
+ return FALSE;
+}
+
+static void
+ephy_icon_entry_get_borders (GtkWidget *widget,
+ GtkWidget *entry,
+ int *xborder,
+ int *yborder)
+{
+ int focus_width;
+ gboolean interior_focus;
+
+ g_return_if_fail (entry-style != NULL);
+
+ gtk_widget_style_get (entry,
+ focus-line-width, focus_width,
+ interior-focus, interior_focus,
+ NULL);
+
+ *xborder = entry-style-xthickness;
+ *yborder = entry-style-ythickness;
+
+ if (!interior_focus)
+ {
+ *xborder += focus_width;
+ *yborder += focus_width;
+ }
+}
+
+static void
+ephy_icon_entry_paint (GtkWidget *widget,
+ GdkEventExpose *event)
+{
+ EphyIconEntry *entry = EPHY_ICON_ENTRY (widget);
+ GtkWidget *entry_widget = entry-entry;
+ int x = 0, y = 0, width, height, focus_width;
+ gboolean interior_focus;
+
+ gtk_widget_style_get (entry_widget,
+ interior-focus, interior_focus,
+ focus-line-width, focus_width,
+ NULL);
+
+ gdk_drawable_get_size (widget-window, width, height);
+
+ if (GTK_WIDGET_HAS_FOCUS (entry_widget) !interior_focus)
+ {
+ x += focus_width;
+ y += focus_width;
+ width -= 2 * focus_width;
+ height -= 2 * focus_width;
+ }
+
+ gtk_paint_flat_box (entry_widget-style, widget-window,
+ GTK_WIDGET_STATE (entry_widget), GTK_SHADOW_NONE,
+ NULL, entry_widget, entry_bg,
+ /* FIXME: was 0, 0 in gtk_entry_expose, but I think this is correct: */
+ x, y, width, height);
+
+ gtk_paint_shadow (entry_widget-style, widget-window,
+ GTK_STATE_NORMAL, GTK_SHADOW_IN,
+ NULL, entry_widget, entry,
+ x, y, width, height);
+
+ if (GTK_WIDGET_HAS_FOCUS (entry_widget) !interior_focus)
+ {
+ x -= focus_width;
+ y -= focus_width;
+ width += 2 * focus_width;
+ height += 2 * focus_width;
+
+ gtk_paint_focus (entry_widget-style, widget-window,
+ GTK_WIDGET_STATE (entry_widget),
+ NULL, entry_widget, entry,
+ /* FIXME: was 0, 0 in gtk_entry_draw_frame, but I think this is correct: */
+ x, y, width, height);
+ }
+}
+
+/* Class implementation */
+
+static void
+ephy_icon_entry_init (EphyIconEntry *entry)
+{
+ EphyIconEntryPrivate *priv;
+ GtkWidget *widget = (GtkWidget *) entry;
+
+
Re: [Ekiga-devel-list] URI ComboBoxEntry
On Mon, 11 Sep 2006 16:09:45 +0200 Daniel Smertnig [EMAIL PROTECTED] wrote: On 9/11/06, Jan Schampera [EMAIL PROTECTED] wrote: While you were writing the last few mails I dug into that stuff. If you already have working code, can you share it? The patch is attached (although I developed it against a version which Just curious, what is the purpose of that padlock icon? Secure/Insecure connections? J. -- Be liberal in what you accept, and conservative in what you send. - J. B. Postel, master of the net. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] URI ComboBoxEntry
On Mon, 11 Sep 2006 16:48:26 +0200 Damien Sandras [EMAIL PROTECTED] wrote: I guess it's 100% gtk+, and hence will give 0% more issues on win32 ? Wouldn't it be better to place that icon in the status bar than in the location entry? That's why I asked for the purpose of the padlock-icon in another sub-thread. It also could be placed between URL: and the entry field, though the status-bar makes more sense. Also IMHO if it's IN the URL field, it should be an object derived from GtkComboBox where the GtkComboBoxEntry stuff is re-implemented. Or something around these lines, don't pin me on that (I guess deriving from GtkComboBoxEntry makes more sense). J. -- God is real... unless declared as integer. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] preliminary patch for X-Video support
mcquaid mcquaid [EMAIL PROTECTED] writes: I'm just a user but with a couple of questions. I thought that sdl can have access to hardware overlay? Also, I thought that only 1 window can have access to hardware overlay, so how is pip dealt with in this regard? Depending on your graphics card you can have multiple XVideo ports. Matrox cards, for example, support using textures to handle XVideo in which case they give you 32 ports. -- greg ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
