Nabble - Php - GTK - General

Re: PHP-GTK on Mac OS X 10.4

2009-11-04T08:15:33Z

Hi,

just to say I have exactly the same problem which is a big frustration
even more when you see the promising screen captures of the installer...

php-gtk-general

2009-09-23T05:50:58Z

php-gtk-general

Gtk2 Popup on GtkEntry

2009-09-15T23:32:18Z

Maybe this is obvious, but I just stumbled across the default popup menu for
GtkEntry. The default selections will not do for our users; they freak
easily.

Is it possible to get to those selections and change them, or do I need to
override the popup?

thanks,
Madeleine D.

Re: error in constructor

2009-08-31T10:58:21Z

On Mon, Aug 31, 2009 at 1:32 PM, Benjamin FOURTICQ <
benjamin.fourticq@...> wrote:

> I imagine the constructor is called twice, because when you call $toto =
> new ProjectList()
> ProjectList::__construct() is called and so GtkTreeview::__construct(),
> then ProjectList::ProjectList() because it exists.
>
>
That is not correct, if there's a ProjectList::__construct() method that
will be called as the constructor and not ProjectList::ProjectList().
ProjectList::ProjectList() only gets called if there is no
ProjectList::__construct() for backwards compatibility.

>
> Le 31/08/2009 19:07, Der Starchaser a écrit :
>
>
>> I want to program a class ProjectList, which is derived from class
>> GtkTreeView. The following code snippet results in an assertion error. Is
>> anybody able to explain me the error ?
>>
>
>

Your assertion fails because there are no columns in the view. See:
http://gtk.php.net/manual/en/gtk.gtktreeview.php

Specifically:

"After creating the view and setting the model, you need to create some
GtkTreeViewColumns and add them to the view with append_column() . The
column widgets themselves need some GtkCellRenderers that actually draw and
display the data of the model."

-Jake

Re: error in constructor

2009-08-31T10:50:13Z

Benjamin FOURTICQ wrote:

> I imagine the constructor is called twice, because when you call $toto =
> new ProjectList()
> ProjectList::__construct() is called and so GtkTreeview::__construct(),
> then ProjectList::ProjectList() because it exists.
> In my opinion, if you just need to set the model use set_model() instead
> of calling the prent constructor.
>
> Hope this helps,
> Benjamin.
>
> Le 31/08/2009 19:07, Der Starchaser a écrit :
>>
>> I want to program a class ProjectList, which is derived from class
>> GtkTreeView. The following code snippet results in an assertion error. Is
>> anybody able to explain me the error ?
>>
>>
>> class ProjectList extends GtkTreeView
>> {
>>
>> protected $store;
>>
>> /***********************************************************/
>> /* Constructor Method
>> /***********************************************************/
>> function ProjectList()
>> {
>>
>> $this->store = new GtkListStore(
>> GObject::TYPE_STRING, GObject::TYPE_STRING
>> );
>>
>> parent::__construct( $this->store );
>>
>> $col = 0;
>> $column = $this->get_column(0);
>> assert( $column ); //<- this line throws an
>> assertion error
>> $cell_renderer = new GtkCellRendererPixbuf();
>> $column->pack_start($cell_renderer, false);
>>
>> $column->set_cell_data_func(
>> $cell_renderer,
>> "prjlist_format_pixbuf",
>> $this->Pixmap
>> );
>>
>> }
>>
>> } // of class
>>
>>
>

ugh - if you want to override the constructor that's fine - do it using

public function __construct() {}

PHP 5 uses unified constructors - the "use the same function as the
class name" support is a holdover for BC, please please don't use it in
new code.... as you see it has some seriously odd side effects

see the manual http://php.net/oop5.decon

Thanks,
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: error in constructor

2009-08-31T10:32:18Z

I imagine the constructor is called twice, because when you call $toto =
new ProjectList()
ProjectList::__construct() is called and so GtkTreeview::__construct(),
then ProjectList::ProjectList() because it exists.
In my opinion, if you just need to set the model use set_model() instead
of calling the prent constructor.

Hope this helps,
Benjamin.

Le 31/08/2009 19:07, Der Starchaser a écrit :

>
> I want to program a class ProjectList, which is derived from class
> GtkTreeView. The following code snippet results in an assertion error. Is
> anybody able to explain me the error ?
>
>
> class ProjectList extends GtkTreeView
> {
>
> protected $store;
>
> /***********************************************************/
> /* Constructor Method
> /***********************************************************/
> function ProjectList()
> {
>
> $this->store = new GtkListStore(
> GObject::TYPE_STRING, GObject::TYPE_STRING
> );
>
> parent::__construct( $this->store );
>
> $col = 0;
> $column = $this->get_column(0);
> assert( $column ); //<- this line throws an assertion error
> $cell_renderer = new GtkCellRendererPixbuf();
> $column->pack_start($cell_renderer, false);
>
> $column->set_cell_data_func(
> $cell_renderer,
> "prjlist_format_pixbuf",
> $this->Pixmap
> );
>
> }
>
> } // of class
>
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

error in constructor

2009-08-31T10:07:51Z

I want to program a class ProjectList, which is derived from class
GtkTreeView. The following code snippet results in an assertion error. Is
anybody able to explain me the error ?

class ProjectList extends GtkTreeView
{

protected $store;

/***********************************************************/
/* Constructor Method
/***********************************************************/
function ProjectList()
{

$this->store = new GtkListStore(
GObject::TYPE_STRING, GObject::TYPE_STRING
);

parent::__construct( $this->store );

$col = 0;
$column = $this->get_column(0);
assert( $column ); // <- this line throws an assertion error
$cell_renderer = new GtkCellRendererPixbuf();
$column->pack_start($cell_renderer, false);

$column->set_cell_data_func(
$cell_renderer,
"prjlist_format_pixbuf",
$this->Pixmap
);

}

} // of class

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: set_pixtext()

2009-08-27T10:00:43Z

CList should be replaced with GtkTreeView. Attach a
GtkCellRendererPixbuf to a given column in the view and use
'set_cell_data_func' to format the cell_renderer. At the callback for
that, you can then isolate a given cell/row and use
'set_property("pixbuf", $image)' to load the pixmap.

hth,
Madeleine D.

Der Starchaser wrote:

> The following old piece of code should be adapted to PHP-GTK 2 :
>
> $this->clistProjects = new GtkCList(1, array($this->ListTitle));
> $node = $this->clistProjects->append(array($Config));
> $this->clistProjects->set_pixtext($node, 0, $Config, 5,
> $this->iconpixmap, $this->iconmask);
>
>
> I found no method which supports the functionality of the old set_pixtext() in
> PHP-GTK 2.
>
> Does anybody know a workaround ?
>
> Thank you
>
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

MULTILINGUAL DICTIONARY linking examples without leaving your web pages

2009-08-27T06:49:36Z

Dear Sir/Madam,

We have now upgraded our MULTILINGUAL DICTIONARY linking examples so that your users will no longer leave your web pages.

For more information, please go to:

http://www.tranexp.com/intertran/linking.cgi?31

We will be very happy to answer any queries you might have.

Best regards,

Translation Experts

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: GtkButtonBox::set_child_size()

2009-08-27T06:38:23Z

GObject::get_property(string) and GObject::set_property(string, mixed)

-Jake

On Thu, Aug 27, 2009 at 2:19 AM, Der Starchaser <TheStarchaser@...>wrote:

> Hello at all,
>
> the code snippet
>
> $bbox = &new GtkHButtonBox();
> $bbox->set_child_size(15, 20);
>
> returns an error :
>
> Warning: GtkButtonBox::set_child_size() is deprecated: don't use
> this
>
> The Manual suggests the following :
>
> GtkButtonBox::set_child_size
>
> void set_child_size(int min_width, int min_height);
>
> Warning! This method is DEPRECATED and should NOT be used in
> newly-written
> code. Use the style properties child-min-width/-height instead.
>
> How do I manipulate the style properties ogf the Box ?
>
> Thank you !
>
> --
> PHP-GTK General Mailing List (http://gtk.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: set_pixtext()

2009-08-27T06:30:41Z

Are you wanting a GdkPixbuf in a GtkTreeView? (Sorry, I'm not familiar with
PHP-GTK1 code)

On Thu, Aug 27, 2009 at 6:46 PM, Der Starchaser <TheStarchaser@...>wrote:

>
>
> The following old piece of code should be adapted to PHP-GTK 2 :
>
> $this->clistProjects = new GtkCList(1,
> array($this->ListTitle));
> $node = $this->clistProjects->append(array($Config));
> $this->clistProjects->set_pixtext($node, 0, $Config, 5,
> $this->iconpixmap, $this->iconmask);
>
>
> I found no method which supports the functionality of the old set_pixtext()
> in
> PHP-GTK 2.
>
> Does anybody know a workaround ?
>
> Thank you
>
> --
> PHP-GTK General Mailing List (http://gtk.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- Chris Morgan <chris.morganiser@...>

I'm good at making two things: mistakes and enemies.

set_pixtext()

2009-08-27T01:46:22Z

The following old piece of code should be adapted to PHP-GTK 2 :

$this->clistProjects = new GtkCList(1, array($this->ListTitle));
$node = $this->clistProjects->append(array($Config));
$this->clistProjects->set_pixtext($node, 0, $Config, 5,
$this->iconpixmap, $this->iconmask);

I found no method which supports the functionality of the old set_pixtext() in
PHP-GTK 2.

Does anybody know a workaround ?

Thank you

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

GtkButtonBox::set_child_size()

2009-08-26T23:19:17Z

Hello at all,

the code snippet

$bbox = &new GtkHButtonBox();
$bbox->set_child_size(15, 20);

returns an error :

Warning: GtkButtonBox::set_child_size() is deprecated: don't use this

The Manual suggests the following :

GtkButtonBox::set_child_size

void set_child_size(int min_width, int min_height);

Warning! This method is DEPRECATED and should NOT be used in newly-written
code. Use the style properties child-min-width/-height instead.

How do I manipulate the style properties ogf the Box ?

Thank you !

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: subclassing GtkMenuItem

2009-08-22T10:27:27Z

use

GtkMenuItem::__construct ( $label );

Am Saturday 22 August 2009 16:34:21 schrieb Der Starchaser:

> hello @ all,
>
> when subclassing GtkMenuItem I receive an error : Fatal error: Call to
> undefined method GtkMenuItem::GtkMenuItem() in MenuItem.class on line 128.
>
> Is there any workaround possible ?
>
>
>
> class MyAltMenuItem extends GtkMenuItem
> {
> function MyAltMenuItem($label, $underscore, $accelgroup)
> {
> GtkMenuItem::GtkMenuItem ( $label ); <------ line 128
> if (strlen($label)!=(strlen($underscore)-1))
> $label = new GtkLabel;
> else
> $label = $this->child;
>
> $Subitem_key = $label->parse_uline($underscore);
> GtkMenuItem::add_accelerator("activate_item", $accelgroup, $Subitem_key,
> GDK_MOD1_MASK, 0);
> }
> }

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

subclassing GtkMenuItem

2009-08-22T07:34:21Z

hello @ all,

when subclassing GtkMenuItem I receive an error : Fatal error: Call to
undefined method GtkMenuItem::GtkMenuItem() in MenuItem.class on line 128.

Is there any workaround possible ?

class MyAltMenuItem extends GtkMenuItem
{
function MyAltMenuItem($label, $underscore, $accelgroup)
{
GtkMenuItem::GtkMenuItem ( $label ); <------ line 128
if (strlen($label)!=(strlen($underscore)-1))
$label = new GtkLabel;
else
$label = $this->child;

$Subitem_key = $label->parse_uline($underscore);
GtkMenuItem::add_accelerator("activate_item", $accelgroup, $Subitem_key,
GDK_MOD1_MASK, 0);
}
}

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: GtkEntryCompletion using keyboard

2009-08-18T12:29:41Z

Hi Madeleine,

Thanks for your reply.
After looking at the code some more, I think my problem is related to having
the model fill in as users type.
The whole list of values is very long so it is in database, and as users
type, I intercept the key-released-event signal, and load the model of the
completion widget accordingly.
I think there must be something related to this that I need to do when the
arrow keys are pressed to avoid the completion widget from not behaving
correctly.

This is the relevant code (it is inside a class thus all the $this):

$calle_actual = "";

if (defined("GObject::TYPE_STRING")) {
$this->model_calle = new GtkListStore(GObject::TYPE_STRING); // note
1
} else {
$this->model_calle = new GtkListStore(Gtk::TYPE_STRING); // note 1
}
$this->completion_calle = new GtkEntryCompletion();
$this->completion_calle->set_model($this->model_calle);
$this->completion_calle->set_text_column(0);

$this->calle = new GtkEntry();
$this->calle->set_text($calle_actual);
$this->calle->set_completion($this->completion_calle_legal);
$this->calle->connect('key-release-event',array(&$this,'update_model_calle'));
$this->completion_calle->connect('key-release-event',array(&$this,'update_calle'));

I think I should make the update_calle function ignore all keys except
Enter, so it updates the gtkentry contents on Enter keypress and ignores
rest of keys.
Do you think that would work? Should function return false for the rest of
the keys?

Thank you!

Veronica

----- Original Message -----
From: "Madeleine D." <chezmmd@...>
To: "Veronica A. Bendersky" <vbendersky@...>
Sent: Tuesday, August 18, 2009 1:33 PM
Subject: Re: [PHP-GTK] GtkEntryCompletion using keyboard

>
> Veronica -
>
> Not sure if you got an answer for this one yet.
>
> We have the same issue; users wanting to avoid mouse action. And we use
> GtkEntryCompletion on many of our screens w/o problems.
> Could you maybe post the relevant code?
>
> thanks,
> Madeleine D.
>
>
> Veronica A. Bendersky wrote:
>> Hi,
>>
>> I have tried to use gtkentrycompletion, it works ok if I use the mouse to
>> select an alternative, but if I want to use the keyboard only (which is
>> something my users want to do since they're just typing info in and want
>> to avoid the mouse as much as possible inside the entry screen), then it
>> seems that the gtkentrycompletion keeps losing focus and I cannot move
>> inside the list or select a suggested option just using the arrows and
>> enter or tab. Is there a way to make gtkentrycompletion work without
>> using the mouse to select an option?
>>
>> Thanks!
>> Veronica

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

pixmap_create_from_xpm()

2009-08-17T20:47:52Z

Trying to create pixmaps I receive an error " Call to undefined method
Gdk::pixmap_create_from_xpm() ". Is there any workaround to use pixmaps ?

$PixStart = Gdk::pixmap_create_from_xpm($this->StartWindow->window,
null, 'interface/start_new.xpm');
$Start = new GtkPixmap($PixStart[0], $PixStart[1]);

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

GtkEntryCompletion using keyboard

2009-08-17T06:36:19Z

Hi,

I have tried to use gtkentrycompletion, it works ok if I use the mouse to select an alternative, but if I want to use the keyboard only (which is something my users want to do since they're just typing info in and want to avoid the mouse as much as possible inside the entry screen), then it seems that the gtkentrycompletion keeps losing focus and I cannot move inside the list or select a suggested option just using the arrows and enter or tab. Is there a way to make gtkentrycompletion work without using the mouse to select an option?

Thanks!
Veronica

popup combobox on pressing enter in a GtkComboboxEntry

2009-08-13T03:21:32Z

hi.
how can i do this?

it seems that :

<?php
$shopLogCombobox = $glade->get_widget('shopLogCombobox');
$shopLogCombobox->connect_simple('editing-done', 'test');
?>

or

<?php
$shopLogCombobox = $glade->get_widget('shopLogCombobox');
$shopLogCombobox->get_child()->connect_simple('editing-done', 'test');
?>

does not work.

thx

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Contribute with the docs

2009-06-30T09:59:18Z

Fernando -

If that's doable, I think it would be a great help. Finding the time
for the markup is not possible for a lot of us right now.

Madeleine D.

Fernando Correa da Conceição wrote:
> There was a previous thread about the status of php-gtk and the docs.
> Some people wants help but do not know the xml markup and how the
> things works.
> So I have a simple proposal for then: write the docs as a simple text,
> i will add the xml markup and commit the docs to cvs.
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Contribute with the docs

2009-06-30T09:49:17Z

There was a previous thread about the status of php-gtk and the docs.
Some people wants help but do not know the xml markup and how the things
works.
So I have a simple proposal for then: write the docs as a simple text, i
will add the xml markup and commit the docs to cvs.

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Hi friend,

2009-06-22T12:55:49Z

Robertico wrote:

> *Hi friend,
> how are you doing recently ? I would like to introduce you a very good
> company which i knew.Their website is
> **www.elewholesale.com*<http://www.elewholesale.com/>
> * .They can offer you all kinds of electronical products which you need
> like laptops ,gps ,TV LCD,cell phones,ps3,MP3/4,motorcycles
> etc........Please take some time to have a check ,there must be somethings
> you 'd like to purchase .
> Their contact email: **eleintrade@...* <eleintrade@...>*. *
> * MSN:
> **ele1wholesale@...*<eleintrade01@...>
> * **
> Hope you have a good mood in shopping from their company !
>
> Regards*
>

I hope you die a painful death. :D

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Hi friend,

2009-05-21T09:14:17Z

*Hi friend,
how are you doing recently ? I would like to introduce you a very good
company which i knew.Their website is
**www.elewholesale.com*<http://www.elewholesale.com/>
* .They can offer you all kinds of electronical products which you need
like laptops ,gps ,TV LCD,cell phones,ps3,MP3/4,motorcycles
etc........Please take some time to have a check ,there must be somethings
you 'd like to purchase .
Their contact email: **eleintrade@...* <eleintrade@...>*. *
* MSN:
**ele1wholesale@...*<eleintrade01@...>
* **
Hope you have a good mood in shopping from their company !

Regards*

Copy/Paste on OSX?

2009-05-13T16:08:16Z

I'm running PHP-GTK 1 on MacOSX and have run into an interesting problem.

Copy/Paste works fine on OSX, but I have to use Control-C and Control-V for GTK
apps but Cmd-C and Cmd-V for other applications.

How could I go about changing this?

-Ben

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Status of PHP-GTK

2009-04-20T07:50:44Z

Elizabeth M Smith wrote:
> Yikes - I was gone for the weekend and ...

Tell me about it :)

> For those asking for a wiki - php.net currently has a wiki up
> (wiki.php.net) and it's so far been a very good experience. However
> access is controlled pretty well (cvs access credentials and cvs karma
> are used, in additional other users can register and are given access to
> certain areas after mailing the php.webmaster list)

That's on Pierre's box, no?
The main problem with making the wiki part of the gtk.php.net site was that we don't know whose server we're going to be on next week, if you follow.

> As a compromise could we maybe have a php-gtk section on the wiki for
> those that want to put up tips, keep track of the doc migration status
> (maybe I'd stop being lazy and put up a page with what I'm currently
> playing with)
>
> Just an idea.

Not a bad idea either.

> and Steph, if you'd have some time to talk to leon, mgdm and frozenfire
> they'd love some help. I have a cursory understanding of the system but
> they need someone who knows the phpgtkdoc.dtd and can "merge in" the
> parts that will be needed above and beyond the php.net's .dtd ;)

I went to talk to them but they didn't talk back - I guess we're all in different timezones. (Actually frozenfire did eventually speak - he was on his way out to work, and it was 9pm here.) If they'd contact me via email it'd be easier.

Cheers,

- Steph

>
> Thanks,
> Elizabeth
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-20T07:30:54Z

Yikes - I was gone for the weekend and ...

For those asking for a wiki - php.net currently has a wiki up
(wiki.php.net) and it's so far been a very good experience. However
access is controlled pretty well (cvs access credentials and cvs karma
are used, in additional other users can register and are given access to
certain areas after mailing the php.webmaster list)

As a compromise could we maybe have a php-gtk section on the wiki for
those that want to put up tips, keep track of the doc migration status
(maybe I'd stop being lazy and put up a page with what I'm currently
playing with)

Just an idea.

and Steph, if you'd have some time to talk to leon, mgdm and frozenfire
they'd love some help. I have a cursory understanding of the system but
they need someone who knows the phpgtkdoc.dtd and can "merge in" the
parts that will be needed above and beyond the php.net's .dtd ;)

Thanks,
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-18T13:11:18Z

On Saturday 18 April 2009 11:32:01 you wrote:
> XML is Yet Another Documentation Language?

The specific schema used is what I refer to as "yet another documentation
language". It's not that knowing XML is an issue, it's that knowing all the
rules, ramifications and permutations of this schema that's the issue.

> These PHP tools (AKA phd) simply build the docs. You can try it out with
> phpdoc, where it's already used, if you're interested. It renders a whole
> lot faster than xsltproc, and it also means you don't need any further
> tools beyond PHP itself to build the manual. I'm not 100% sure what the
> benefit of live updates is - possibly the idea is that you can build the
> docs locally then make alterations via the browser, rebuild to test,
> commit. That would make sense because it removes the XML 'barrier to
> entry'.

Tell me more about this "live updates"... ?

> > But that information is still very useful information to somebody using
> > PHP- GTK!
>
> So we fix user notes et voila, the info is available.

Forward progress is forward progress - I strongly agree with this next step!

> What's the difference, really? Inaccurate or weak info can be deleted
> anyway, or moved into the manual and given 'official' status. There are a
> _lot_ of people with php-gtk-doc access, and over 2,000 people with access
> to notes admin (both for the PHP manual and for the PHP-GTK manual, anyone
> with a php.net account of any kind can edit user notes.)

I did not know this.

> > This would provide basically three tiers of documentation on the same
> > page:
> >
> > 1) The "root" documentation, in the tagged documentation format, edited
> > only by language developers.
>
> Why so? I wrote half the first manual without being a language developer. I
> also wrote a previous unofficial manual from a user perspective, back in
> the day; the biggest problem with that was that I didn't know why things
> were as they were, so I couldn't explain behaviours.

I applaud your efforts, sir! Thank you thank you thank you! There was another
comment recently about doing "proper research" of which I was thinking.

PS: Thank you!

> We could (once notes are rolling) open up access to notes. There is a
> precedent for this: there are people with editing rights for the PHP manual
> notes who do not have a CVS account.

Great!

> I had it to trial status before now; still in CVS; nobody's touched it in
> the last 3 years but it doesn't mean the code isn't there. In fact I've
> been looking at it today... the problems with it were 1) I hadn't made it
> easy to set up a local version (have done so locally now), and 2) I'd some
> clever idea about using the php.net NNTP server rather than actual people
> to control the notes queue. That part really didn't pan out and I'll
> happily spend the next hour or so killing it. The rest of the system
> appears to work fine, just we'd need willing moderators to join the ML
> where notifications are sent. According to the config file, that would be
> the php-gtk-webmaster list.

// SNIP //

> > The wiki itself (EG: phpwiki) can be hosted at an unpublished url, and
> > can be password protected.
>
> What's the difference between a password-protected wiki and
> password-protected notes admin?

I was picturing something that visually would look as if the wiki section was
more part of the documentation at the top, rather than a "note" which 27
followups improving on a bad code sample. (as has already been complained
about)

Myself, I've LOVED the notes in the PHP-GTK website - just do a search for my
email address as a contributor in the phpgtk1 docs. I make it a point to leave
a note anytime I had to do further searching to get a job I'm trying to do,
done.

BTW: I have a fairly large, stable code base written in PHP-GTK1 and the cost
of jumping to php-gtk2 is pretty high, so I haven't made the switch, yet. I've
contemplated building a set of wrappers so that there are widgets in PHP5-GTK2
that have a similar API to comparable widgets PHP4-GTK1, and I've even started
a few times, but that's another story.

> I'd be bothered about hosting a wiki on a php.net server again, following
> the experience we had last time around. So the part about the 'unpublished
> url' sounds good, but then - Frederic has a rather good community site that
> already offers this kind of approach. Why not just make more of the
> community sites from the project homepage, thereby allowing php.net to do
> what it does best and the community sites to do what they do best?

Wikis have their problems. Did you read about the P2P network set up at a
college on the US East Coast using wikis as the distribution medium?

But they are very useful! Here's what I do in order to tie documentation in a
Wiki to a section of a complex website. I haven't checked this for bugs, but
it should give the idea. And if this is already patently obvious, please be
gentle.

Let's say you have a page, and you want to embed content from a wiki elsewhere
in there.

http://www.mydomain.com/path/to/index.php

0) Edit the wiki's templates so that the below comment tags appear just
before/after the changeable content on each wiki page.

1) within the file index.php, In PHP, turn that into a wiki word. EG:
$tmp = preg_replace("/[^a-zA-Z]/", ' ', $_SERVER['SCRIPT_NAME']);
$wikiword = str_replace(' ', '', ucfirst(strtolower($tmp));
Now $wikiword should have something like 'PathToIndexPhp';

2) Now, get the wiki content, stick it into the page.
$url="http://$htuser:$htpass@...?page=$wikiword";

// YOU SHOULD HAVE EMBEDDED THESE TAGS INTO THE WIKI
// TEMPLATE SO WE CAN EXTRACT THE CONTENT HERE
$contentBegins = '';
$contentEnds='';
$content=file_get_contents($url)
echo substsr($content,
strpos($content, $contentBegins)+strlen($contentBegins),
strpos($content, $contentEnds));

I usually leave a link to the wiki in the output so that those with
appropriate passwords can "jump right in" if they notice a documentation bug.
Of course, they'll need to enter the password:

echo "<A HREF='http://wiki.mydomain.com?page=$wikiword'>edit</a>";

This is obviously a very simple form - I usually have to re-map links within
the content from the wiki to maintain cohesion, and a few other details. But
it's not hard, and it works very, very well for me, in that I can effectively
let the support staff at my company (who aren't programmers but who answer the
phones) update the documentation in a way that looks "official" in real-time.

I use Apache .htaccess passwords to protect the wiki from abuse.

-Ben

PS: If you are still reading, thank you again!

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-18T11:34:09Z

Andrei Zmievski wrote:
> Steph wrote:
>> It sounds to me like those who want to contribute to the documentation
>> would rather do it in a user-notes kinda way than actually contribute
>> to the documentation. I.e. not need to do the background work like
>> checking the GTK manual or source, kind of thing. That's totally
>> understandable, but I think blaming the use of XML is a bit mean when
>> really it's the lack of user notes that's the issue.
>
> So, when can we have user notes back?

I'm on it. It wasn't actually as bad as I remembered - just the NNTP-checking stuff was a seriously bad idea.

- Steph
>
> -Andrei
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-18T11:32:01Z

Hi Benjamin,

> This scenario is exactly what's got this list so active over the past few
> days. You're not the only one in this exact boat. Picking up YADL (Yet Another
> Documentation Language) is something that raises the bar to contribution
> considerably.

XML is Yet Another Documentation Language?

> Due to the PHP.net frameworks and tools that already exist, there is good
> reason to stick with their documentation format at the cost of making it
> considerably more difficult (less likely) for developers (such as Madeleine and
> myself) who write lots of PHP-GTK code but don't actually develop the code
> base itself to contribute documentation. I can't comment on the quality of
> these PHP tools, but I'm sure they are quite useful for administrators.

These PHP tools (AKA phd) simply build the docs. You can try it out with phpdoc, where it's already used, if you're interested. It renders a whole lot faster than xsltproc, and it also means you don't need any further tools beyond PHP itself to build the manual. I'm not 100% sure what the benefit of live updates is - possibly the idea is that you can build the docs locally then make alterations via the browser, rebuild to test, commit. That would make sense because it removes the XML 'barrier to entry'.

> But I am not likely to dive into source code and learn a new documentation
> markup language so that I can authoritatively document that you have to
> reference a child widget in a particular, non-standard way with widget XYZ.
>
> But that information is still very useful information to somebody using PHP-
> GTK!

So we fix user notes et voila, the info is available.

> Would it be possible to embed an wiki into the documentation so that
> inaccurate or weak information can be simply deleted? (rather than just
> commented on, as in comments)

What's the difference, really? Inaccurate or weak info can be deleted anyway, or moved into the manual and given 'official' status. There are a _lot_ of people with php-gtk-doc access, and over 2,000 people with access to notes admin (both for the PHP manual and for the PHP-GTK manual, anyone with a php.net account of any kind can edit user notes.)

> This would provide basically three tiers of documentation on the same page:
>
> 1) The "root" documentation, in the tagged documentation format, edited only
> by language developers.

Why so? I wrote half the first manual without being a language developer. I also wrote a previous unofficial manual from a user perspective, back in the day; the biggest problem with that was that I didn't know why things were as they were, so I couldn't explain behaviours.

> 2) The "wiki" documentation, edited only by proven PHP-GTK developers who
> aren't necessarily up to #1 above, but have been given access to update the
> wiki-appended documentation,

We could (once notes are rolling) open up access to notes. There is a precedent for this: there are people with editing rights for the PHP manual notes who do not have a CVS account.

> 3) Comments, contributed by end users.
>
> This isn't hard to set up since string manipulation is PHP's home turf, and I
> *am* volunteering to help set this up.

I had it to trial status before now; still in CVS; nobody's touched it in the last 3 years but it doesn't mean the code isn't there. In fact I've been looking at it today... the problems with it were 1) I hadn't made it easy to set up a local version (have done so locally now), and 2) I'd some clever idea about using the php.net NNTP server rather than actual people to control the notes queue. That part really didn't pan out and I'll happily spend the next hour or so killing it. The rest of the system appears to work fine, just we'd need willing moderators to join the ML where notifications are sent. According to the config file, that would be the php-gtk-webmaster list.

Anyone with a php.net address can log into the admin page, but auth is further restricted via whitelisting for some activities. Restricted access does not currently include the ability to edit the existing notes (from the former manual), but does include core items like the ability to turn notes or email notifications on or off.

> I've done something similar in commercial web-based products I've worked on in
> the past, so that "administrators" (non-programming staff) can update
> documentation easily for a given page of our product without making them be
> programmers. It works rather well. Typically, I fashion a wiki-url with a bit
> of string manipulation from the URL of the page, and make an RPC call to the
> wiki to get the document(s) in question.
>
> The wiki itself (EG: phpwiki) can be hosted at an unpublished url, and can be
> password protected.

What's the difference between a password-protected wiki and password-protected notes admin?

I'd be bothered about hosting a wiki on a php.net server again, following the experience we had last time around. So the part about the 'unpublished url' sounds good, but then - Frederic has a rather good community site that already offers this kind of approach. Why not just make more of the community sites from the project homepage, thereby allowing php.net to do what it does best and the community sites to do what they do best?

- Steph

>
> -Ben
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-18T11:30:35Z

Steph wrote:
> It sounds to me like those who want to contribute to the documentation
> would rather do it in a user-notes kinda way than actually contribute to
> the documentation. I.e. not need to do the background work like checking
> the GTK manual or source, kind of thing. That's totally understandable,
> but I think blaming the use of XML is a bit mean when really it's the
> lack of user notes that's the issue.

So, when can we have user notes back?

-Andrei

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-17T12:54:16Z

On Friday 17 April 2009 08:28:09 Justin Martin wrote:
> I am quite well versed in PHP-GTK,
> but I know next to nothing about the documentation system.

This scenario is exactly what's got this list so active over the past few
days. You're not the only one in this exact boat. Picking up YADL (Yet Another
Documentation Language) is something that raises the bar to contribution
considerably.

It's a horrible choice: Red Pill or Blue Pill?

Due to the PHP.net frameworks and tools that already exist, there is good
reason to stick with their documentation format at the cost of making it
considerably more difficult (less likely) for developers (such as Madeleine and
myself) who write lots of PHP-GTK code but don't actually develop the code
base itself to contribute documentation. I can't comment on the quality of
these PHP tools, but I'm sure they are quite useful for administrators.

But I am not likely to dive into source code and learn a new documentation
markup language so that I can authoritatively document that you have to
reference a child widget in a particular, non-standard way with widget XYZ.

But that information is still very useful information to somebody using PHP-
GTK!

Would it be possible to embed an wiki into the documentation so that
inaccurate or weak information can be simply deleted? (rather than just
commented on, as in comments)

This would provide basically three tiers of documentation on the same page:

1) The "root" documentation, in the tagged documentation format, edited only
by language developers.
2) The "wiki" documentation, edited only by proven PHP-GTK developers who
aren't necessarily up to #1 above, but have been given access to update the
wiki-appended documentation,
3) Comments, contributed by end users.

This isn't hard to set up since string manipulation is PHP's home turf, and I
*am* volunteering to help set this up.

I've done something similar in commercial web-based products I've worked on in
the past, so that "administrators" (non-programming staff) can update
documentation easily for a given page of our product without making them be
programmers. It works rather well. Typically, I fashion a wiki-url with a bit
of string manipulation from the URL of the page, and make an RPC call to the
wiki to get the document(s) in question.

The wiki itself (EG: phpwiki) can be hosted at an unpublished url, and can be
password protected.

-Ben

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-17T08:28:09Z

Right now, I (FrozenFire), mgdm, and leon are working on generating the
documentation. I have patched the phpdoc docgen.php script to generate
docs for PHP-GTK, except for non-standard stuff like signals.

What we _really_ need is for someone who is quite fluent in the main
documentation system to lend a hand. I am quite well versed in PHP-GTK,
but I know next to nothing about the documentation system. If someone
can pop onto #php-gtk on Freenode, we can get the documentation updated
in a matter of days.

Thanks,
Justin Martin

Steph wrote:

> Andrei Zmievski wrote:
>> Elizabeth M Smith wrote:
>>>> I'd be inclined to branch php-gtk-doc now and adapt the current
>>>> serverside scripts to use that branch while work's in progress on
>>>> upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin
>>>> to hit on everything at the same time rather than pester him twice
>>>> over.
>>> Sounds good.
>>
>> It sounds to me like the current doc system is a big barrier to entry
>> for those who want to contribute to the documentation.
>
> It sounds to me like those who want to contribute to the documentation
> would rather do it in a user-notes kinda way than actually contribute to
> the documentation. I.e. not need to do the background work like checking
> the GTK manual or source, kind of thing. That's totally understandable,
> but I think blaming the use of XML is a bit mean when really it's the
> lack of user notes that's the issue.
>
> To summarize my
>> feelings on this subject: I'd rather have a non-php.net-standard doc
>> system that works and allows easy contributions that be stuck in the
>> current rut.
>
> Keeping a php.net-standard system means there are always people capable
> of fixing it when it breaks. Right now, keeping a php.net-standard
> system also means we should get access to phd, which is a fast-rendering
> PHP based manual build system (no extra tools required, no not even
> xsltproc). That factor alone makes it a good investment; the current
> work on live editing, I'm less convinced about, unless I've
> misunderstood something major. (Mirrors????)
>
> - Steph
>
>>
>> -Andrei
>>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-17T08:06:11Z

Andrei Zmievski wrote:
> Elizabeth M Smith wrote:
>>> I'd be inclined to branch php-gtk-doc now and adapt the current
>>> serverside scripts to use that branch while work's in progress on
>>> upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin
>>> to hit on everything at the same time rather than pester him twice over.
>> Sounds good.
>
> It sounds to me like the current doc system is a big barrier to entry
> for those who want to contribute to the documentation.

It sounds to me like those who want to contribute to the documentation would rather do it in a user-notes kinda way than actually contribute to the documentation. I.e. not need to do the background work like checking the GTK manual or source, kind of thing. That's totally understandable, but I think blaming the use of XML is a bit mean when really it's the lack of user notes that's the issue.

To summarize my
> feelings on this subject: I'd rather have a non-php.net-standard doc
> system that works and allows easy contributions that be stuck in the
> current rut.

Keeping a php.net-standard system means there are always people capable of fixing it when it breaks. Right now, keeping a php.net-standard system also means we should get access to phd, which is a fast-rendering PHP based manual build system (no extra tools required, no not even xsltproc). That factor alone makes it a good investment; the current work on live editing, I'm less convinced about, unless I've misunderstood something major. (Mirrors????)

- Steph

>
> -Andrei
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-17T06:29:39Z

Hi Jace,

Jace Ferguson wrote:
> First of all, I'm excited to see all the recent activity these past few
> days.

Good, ennit? :)

> My opinion on the docs is to stick with the php.net standard.

Mine too, because we get concrete assistance from the rest of php.net if we take this approach.

I think
> migrating the current system to docbook v5 should be a priority.

It should. The work should be stored in CVS HEAD, which means the current docs should be branched and the scripts updated on the server to reflect the new branch name as part of the fixes needed there. (I'm assuming there have actually been updates that weren't followed by a new build..)

Elizabeth
> mentioned in an earlier email that someone had already started the
> migration. I'd like to find out who

So would I...

because in about two weeks I will have
> quite a bit of free time and I'd be willing to help get the docs migrated
> and available for updates.

Woo hoo!

- Steph

> Those are just my thoughts. I'll have the time regardless so I will
> definitely find something to do.
>
>
>
> Jace
>
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Status of PHP-GTK

2009-04-16T15:23:12Z

First of all, I'm excited to see all the recent activity these past few
days.

My opinion on the docs is to stick with the php.net standard. I think
migrating the current system to docbook v5 should be a priority. Elizabeth
mentioned in an earlier email that someone had already started the
migration. I'd like to find out who because in about two weeks I will have
quite a bit of free time and I'd be willing to help get the docs migrated
and available for updates.

Those are just my thoughts. I'll have the time regardless so I will
definitely find something to do.

Jace