Semi-dinamical UIs

[David López Luengo]

Hi there!

I'm starting to use glade and I get a doubt about it's potential. Figure out this situation, I have a part of UI in my application that is allways the same, so I can develop it with glade, but there is some other parts that need to be develop AFTER the user introduce to the program some data. In my case I will try to read an xml description of certain structures and then I want to create (for example) a box with buttons inside it for each field in the structure, give them names properly as the xml description says, let the user add values to the fields, link tooltips to each field and much more functionality. We could understand this as a "semi-dinamical" UI's, I mean "semi" because all this data will be read at start time, not the whole runtime, but neither at develop time, so I don't know if I could use glade to do this... templates or something like this. Do you know if this kind of stuff is pretencious with glade?

Thanks!


--
David

PD: By the way, excuse my english, I'm spanish :$

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[paskari]

Hello

Has anyone figured out why so many people run into the "hide-on-
delete" dilemma. It should be trivial

def hide_window(widget,data,wtree):
        widget.hide()
        return True

        window.connect('delete-event',hide_window)

but everyone, myself included, runs into this problem. I suspect it's  
glade related

http://www.mail-archive.com/pygtk@.../msg17021.html
https://answers.launchpad.net/gladex/+question/9890
http://ubuntuforums.org/archive/index.php/t-135821.html
_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Tristan Van Berkom-2]

On Sat, Oct 17, 2009 at 9:32 AM, Peyman <paskari007@...> wrote:

> Hello
>
> Has anyone figured out why so many people run into the "hide-on-
> delete" dilemma. It should be trivial
>
> def hide_window(widget,data,wtree):
>        widget.hide()
>        return True
>
>        window.connect('delete-event',hide_window)
>
> but everyone, myself included, runs into this problem. I suspect it's
> glade related

Peyman,
   There are a number of things we can do in Glade to make GTK+
easier to use - the fact is though no matter how well we do - the
users of Glade need to have an understanding of the underlying
toolkit GTK+.

The best we can do as far as I can see is try to provide good links
to GTK+ documentation from inside the tool and write good tutorials
or even a user manual about designing GTK+ interfaces with Glade.

A huge problem is that there just isnt enough documentation,
manuals and tutorials out there about using the Glade/GTK+
combination.

Cheers,
      -Tristan

>
> http://www.mail-archive.com/pygtk@.../msg17021.html
> https://answers.launchpad.net/gladex/+question/9890
> http://ubuntuforums.org/archive/index.php/t-135821.html
> _______________________________________________
> Glade-users maillist  -  Glade-users@...
> http://lists.ximian.com/mailman/listinfo/glade-users
>
_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[paskari]

On 17 Oct 2009, at 18:05, Tristan Van Berkom wrote:

> On Sat, Oct 17, 2009 at 9:32 AM, Peyman <paskari007@...> wrote:
>> Hello
>>
>> Has anyone figured out why so many people run into the "hide-on-
>> delete" dilemma. It should be trivial
>>
>> def hide_window(widget,data,wtree):
>>        widget.hide()
>>        return True
>>
>>        window.connect('delete-event',hide_window)
>>
>> but everyone, myself included, runs into this problem. I suspect it's
>> glade related
>
> Peyman,
>   There are a number of things we can do in Glade to make GTK+
> easier to use - the fact is though no matter how well we do - the
> users of Glade need to have an understanding of the underlying
> toolkit GTK+.
>
>
> The best we can do as far as I can see is try to provide good links
> to GTK+ documentation from inside the tool and write good tutorials
> or even a user manual about designing GTK+ interfaces with Glade.
>
> A huge problem is that there just isnt enough documentation,
> manuals and tutorials out there about using the Glade/GTK+
> combination.
>
> Cheers,
>      -Tristan

Tristan

I'm still a little confused as to the situation with respect to hide  
on delete. Is this because Glade does not allow for it, or because I  
am using glade incorrectly?

Cheers


Peyman

>
>
>>
>> http://www.mail-archive.com/pygtk@.../msg17021.html
>> https://answers.launchpad.net/gladex/+question/9890
>> http://ubuntuforums.org/archive/index.php/t-135821.html
>> _______________________________________________
>> Glade-users maillist  -  Glade-users@...
>> http://lists.ximian.com/mailman/listinfo/glade-users
>>

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Tristan Van Berkom-2]

On Sun, Oct 18, 2009 at 11:51 AM, Peyman <paskari007@...> wrote:
>
[...]
> Tristan
>
> I'm still a little confused as to the situation with respect to hide on
> delete. Is this because Glade does not allow for it, or because I am using
> glade incorrectly?

   There is no reason why you cannot connect a callback to the "delete-event"
and call gtk_widget_hide() from that callback - using Glade to design you
GTK+ interface changes nothing in this regard as far as I can see.

The fact that people may not know that they can connect to signals,
or they do not know that they should connect to the delete event
specifically - or the simple fact that they must decide whether
they desire to hide the window when its deleted, or destroy it
and build another one later... all of these facts are details of GTK+,
and it makes no difference if you use Glade or not, you still have
windows which receive delete events and if Im not mistaken the default
action is to destroy the window.

Is there anything specific with regards to using the "delete-event" signal that
you are having problems with ?

Cheers,
       -Tristan
_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[paskari]

On 18 Oct 2009, at 23:34, Tristan Van Berkom wrote:

> On Sun, Oct 18, 2009 at 11:51 AM, Peyman <paskari007@...> wrote:
>>
> [...]
>> Tristan
>>
>> I'm still a little confused as to the situation with respect to  
>> hide on
>> delete. Is this because Glade does not allow for it, or because I  
>> am using
>> glade incorrectly?
>
>   There is no reason why you cannot connect a callback to the  
> "delete-event"
> and call gtk_widget_hide() from that callback - using Glade to  
> design you
> GTK+ interface changes nothing in this regard as far as I can see.
>
> The fact that people may not know that they can connect to signals,
> or they do not know that they should connect to the delete event
> specifically - or the simple fact that they must decide whether
> they desire to hide the window when its deleted, or destroy it
> and build another one later... all of these facts are details of GTK+,
> and it makes no difference if you use Glade or not, you still have
> windows which receive delete events and if Im not mistaken the default
> action is to destroy the window.
>
> Is there anything specific with regards to using the "delete-event"  
> signal that
> you are having problems with ?

Hi Tristan

Yes, I am trying to prevent the delete-event signal from propagating  
further by implementing the following

def delete(...):
        print "Don't delete"
        return True

window.connect ("delete-event",delete)

of course in glade, I connect the callback in the GUI, but the  
function is the same. Now in theory the return value of true should  
stop delete-event from propagating further, but it doesn't. And I have  
tried every variation, such as on destroy, destroy-event, returning  
False, gtk.TRUE, gtk.FALSE.

The only thing I discovered is that it has something to do with the  
run() function which interferes with how the delete-event works

Cheers
Peyman Askari
>
>
> Cheers,
>       -Tristan

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Tadej Borovšak]

Hello.

I'm not sure what is the problem here. Connecting delete-event to some
function that returns TRUE in order to keep window alive should really
not be too difficult.

My Python skills suck, but I did manage to create a working
application in couple of minutes. I attached it below, along with it's
glade file. Hopefully, this app will get you up and running properly.

--- CODE ---
delete-event.py:

#!/usr/bin/env python
# vim: set fileencoding=utf-8

import pygtk
pygtk.require( "2.0" )
import gtk

class SampleApp():
        def __init__( self ):
                builder = gtk.Builder()
                builder.add_from_file( "delete-event.glade" )
                builder.connect_signals( self )

                window = builder.get_object( "window1" )
                window.show()

        def gtk_widget_hide_on_delete( self, widget, event ):
                return widget.hide_on_delete()

        def gtk_main_quit( self, widget ):
                gtk.main_quit()

        def gtk_window_present( self, window ):
                window.present()

def main():
        SampleApp()
        gtk.main()

if __name__ == '__main__':
        main()

delete-event.glade:

<?xml version="1.0"?>
<interface>
  <requires lib="gtk+" version="2.14"/>
  <!-- interface-naming-policy project-wide -->
  <object class="GtkWindow" id="window1">
    <property name="default_width">300</property>
    <property name="default_height">300</property>
    <signal name="destroy" handler="gtk_main_quit"/>
    <child>
      <object class="GtkButton" id="button1">
        <property name="label" translatable="yes">Show popup</property>
        <property name="visible">True</property>
        <property name="can_focus">True</property>
        <property name="receives_default">True</property>
        <signal name="clicked" handler="gtk_window_present" object="window2"/>
      </object>
    </child>
  </object>
  <object class="GtkWindow" id="window2">
    <property name="modal">True</property>
    <property name="default_width">200</property>
    <property name="default_height">200</property>
    <property name="destroy_with_parent">True</property>
    <property name="transient_for">window1</property>
    <signal name="delete_event" handler="gtk_widget_hide_on_delete"/>
    <child>
      <object class="GtkLabel" id="label1">
        <property name="visible">True</property>
        <property name="label" translatable="yes">I'm popup.</property>
      </object>
    </child>
  </object>
</interface>
--- /CODE ---

Tadej

--
Tadej Borovšak
tadeboro.blogspot.com
tadeboro@...
tadej.borovsak@...
_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Alexey Kurochkin]

On Sat, 2009-10-17 at 11:27 +0100, David López Luengo wrote:

> Hi there!
>
> I'm starting to use glade and I get a doubt about it's potential.
> Figure out this situation, I have a part of UI in my application that
> is allways the same, so I can develop it with glade, but there is some
> other parts that need to be develop AFTER the user introduce to the
> program some data. In my case I will try to read an xml description of
> certain structures and then I want to create (for example) a box with
> buttons inside it for each field in the structure, give them names
> properly as the xml description says, let the user add values to the
> fields, link tooltips to each field and much more functionality. We
> could understand this as a "semi-dinamical" UI's, I mean "semi"
> because all this data will be read at start time, not the whole
> runtime, but neither at develop time, so I don't know if I could use
> glade to do this... templates or something like this. Do you know if
> this kind of stuff is pretencious with glade?

There's no templates. You can move your code which creates dynamic UI
into a custom widget. This widget then would read xml description of
your structures and create internal child widgets for each field based
on that. Then you can add this widget to glade through use of a catalog.

Even better, if you have full control over your xml structure
description, then you can make it to be actually GtkBuilder xml. Say you
define object "record" which would hold list of "field" objects with all
required properties, and your custom widget then would create internal
child widgets to reflect your "record" object structure instead of
having to parse xml. This way you can edit and save whole record
definitions directly with glade if you'd wish to do so. Really neat
feature by the way.

In any case you still have to write the code which creates these
internal widgets, so it is up to you to decide if your time worth to be
spent on moving this code to a custom widget. If you have any experience
writing custom widgets, then it shouldn't take too much time, otherwise
go for it only if you want to gain such experience and don't have any
deadlines set.

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Alexey Kurochkin]

On Sat, 2009-10-17 at 14:05 -0300, Tristan Van Berkom wrote:

> On Sat, Oct 17, 2009 at 9:32 AM, Peyman <paskari007@...> wrote:
> > Hello
> >
> > Has anyone figured out why so many people run into the "hide-on-
> > delete" dilemma. It should be trivial
> >
> > def hide_window(widget,data,wtree):
> >        widget.hide()
> >        return True
> >
> >        window.connect('delete-event',hide_window)
> >
> > but everyone, myself included, runs into this problem. I suspect it's
> > glade related
>
> Peyman,
>    There are a number of things we can do in Glade to make GTK+
> easier to use - the fact is though no matter how well we do - the
> users of Glade need to have an understanding of the underlying
> toolkit GTK+.
>
> The best we can do as far as I can see is try to provide good links
> to GTK+ documentation from inside the tool and write good tutorials
> or even a user manual about designing GTK+ interfaces with Glade.
>
> A huge problem is that there just isnt enough documentation,
> manuals and tutorials out there about using the Glade/GTK+
> combination.

I think that fundamental problem is that people consider Glade as some
kind of crappy Linux version of Visual Basic which supposed to make you
feel like you're programmer in five minutes. Glade is just a tool to
free you from routine tasks, but first you have to understand what these
tasks are.

If one expects Glade to jump start anybody on GTK programming it is
deadly wrong. Well, maybe not deadly, but I just want to emphasize the
fact that when you have no experience with GTK and starting to use Glade
then you have to learn BOTH Glade AND GTK at the same time, which makes
things only harder.

The short opening section on the Glade home page is called "What is
Glade?". There probably should be a tad bigger section just below that
one called "What Glade is not?".

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[David López Luengo]

Thanks for the answer very clarifying,

What you mean with "if you have full control over your xml structure
description", maybe you ask if I can (can I) change the syntax structure of my xml files in order to make them GtkBuilder-parseables, don't you?
If it is, yes, they are my own xml files, but I have the requirement of make those files as simpler as possible and I don't want to mix my syntax with glade syntax, it would be nasty for the xml writers, I am not the only one :)

Anyway, it seems that "semi-dinamicals" UIs should be make hardcoded, let's go then, I have no time to lose.

Hope to be skillfull one day writing gtk widgets... right now I'm a newbie xDD and have deadlines so...

Thanks for the answer.


--
David

2009/10/19 Alexey Kurochkin <alexey.kurochkin@...>

On Sat, 2009-10-17 at 11:27 +0100, David López Luengo wrote:
> Hi there!
>
> I'm starting to use glade and I get a doubt about it's potential.
> Figure out this situation, I have a part of UI in my application that
> is allways the same, so I can develop it with glade, but there is some
> other parts that need to be develop AFTER the user introduce to the
> program some data. In my case I will try to read an xml description of
> certain structures and then I want to create (for example) a box with
> buttons inside it for each field in the structure, give them names
> properly as the xml description says, let the user add values to the
> fields, link tooltips to each field and much more functionality. We
> could understand this as a "semi-dinamical" UI's, I mean "semi"
> because all this data will be read at start time, not the whole
> runtime, but neither at develop time, so I don't know if I could use
> glade to do this... templates or something like this. Do you know if
> this kind of stuff is pretencious with glade?

There's no templates. You can move your code which creates dynamic UI
into a custom widget. This widget then would read xml description of
your structures and create internal child widgets for each field based
on that. Then you can add this widget to glade through use of a catalog.

Even better, if you have full control over your xml structure
description, then you can make it to be actually GtkBuilder xml. Say you
define object "record" which would hold list of "field" objects with all
required properties, and your custom widget then would create internal
child widgets to reflect your "record" object structure instead of
having to parse xml. This way you can edit and save whole record
definitions directly with glade if you'd wish to do so. Really neat
feature by the way.

In any case you still have to write the code which creates these
internal widgets, so it is up to you to decide if your time worth to be
spent on moving this code to a custom widget. If you have any experience
writing custom widgets, then it shouldn't take too much time, otherwise
go for it only if you want to gain such experience and don't have any
deadlines set.

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

--
David

_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Alexey Kurochkin]

On Tue, 2009-10-20 at 09:42 +0100, David López Luengo wrote:
> Thanks for the answer very clarifying,
>
> What you mean with "if you have full control over your xml structure
> description", maybe you ask if I can (can I) change the syntax
> structure of my xml files in order to make them GtkBuilder-parseables,
> don't you?

Yes, syntax is the word.

> If it is, yes, they are my own xml files, but I have the requirement
> of make those files as simpler as possible and I don't want to mix my
> syntax with glade syntax, it would be nasty for the xml writers, I am
> not the only one :)

I find GtkBuilder xml quite straight forward and extensible, as long as
your code is "GObject oriented". I've adopted it as a file format for a
program I'm writing right now and so far have no regrets. It saves me
from having to maintain xml parser (with a small exception for handful
of custom tags). It took some time to grasp GObject inner workings
though, cause pretty much the only way to learn is digging through the
GTK sources.

>
> Anyway, it seems that "semi-dinamicals" UIs should be make hardcoded,
> let's go then, I have no time to lose.
>
> Hope to be skillfull one day writing gtk widgets...

GObjects actually. GtkWidgets are just derived from GObject. But it pays
to know the concept. GTK is object oriented at the end.

>  right now I'm a newbie xDD and have deadlines so...

Deadlines make software ugly and programming stressful :(. Good luck
though!


_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users

[Tristan Van Berkom-2]

On Tue, Oct 20, 2009 at 12:01 PM, Alexey Kurochkin
<alexey.kurochkin@...> wrote:
> On Tue, 2009-10-20 at 09:42 +0100, David López Luengo wrote:
[...]

>> Anyway, it seems that "semi-dinamicals" UIs should be make hardcoded,
>> let's go then, I have no time to lose.
>>
>> Hope to be skillfull one day writing gtk widgets...
>
> GObjects actually. GtkWidgets are just derived from GObject. But it pays
> to know the concept. GTK is object oriented at the end.
>
>>  right now I'm a newbie xDD and have deadlines so...
>
> Deadlines make software ugly and programming stressful :(. Good luck
> though!
>

It really is a shame though considering:
 o if you had the right language binding, say pygtk or gtkmm..
 o and you had some half decent documentation or a good tutorial
 o and if we had been able to go an extra mile to allow Glade to
    recognize your custom widget type without writing a small catalog
    (maybe even using rich gir introspection data to do it).

... well then it would really be as simple and natural for you to
write your code inside customized implementations of GTK+
widgets as to write code that runs in callbacks etc, it would
simply be a choice of design case by case.

Anyway just seems we fell just about 5% or 10% short of the mark here...
just too bad I guess.

Cheers,
       -Tristan
_______________________________________________
Glade-users maillist  -  Glade-users@...
http://lists.ximian.com/mailman/listinfo/glade-users