[MonoDevelop] Gtk# GUI Designer?

Sun, 11 Jul 2004 07:53:37 -0500

--=-SR+wER9xQF6HY11cmk5k
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sun, 2004-07-11 at 14:33 +0200, Martin Probst wrote:

> Am So, den 11.07.2004 schrieb Payton Byrd um 14:21:
> > I think that using namespaces fixes the problems described.  You have a
> > basic namespace for "standard" widgets such as buttons and labels, and
> > then each targeted widget would reside in a targeted namespace.
> 
> Yes that would fix it. But without being to negative I think this would
> result in a very limited set of widgets (see xhtml+css). This would
> massively limit the possibilities of the developer.

if each namespace represented a meta-tag that mapped to
implementation-specific complexity, perhaps the namespaces could be
grouped to represent "shelles" of dependancy.  eg.  LCD is the basic
piece and each shell builds on that.  Toolkits can be members of each
namespace.  So, if my toolkit chose getLabel or toText or whatever,
being a member of the TO-TEXT attribute of whatever meta-tag holds label
info...  well, then it would be available in a concrete form at runtime.

> 
> > In the case of Microsoft, they probably won't
> > support GTK widgets directly, but that doesn't mean you cannot create a
> > user control to implement a GTK widget and then map that widget's
> > namespace node to your user control when the XML is parsed to the native
> > language.
> 
> Would you parse the XML and translate it before shipment or on the
> client? In the first case this could be possible, but in the latter it
> would result in the complexity problems I described below.
> 
> These mappings would have to be done for a lot of widgets (nearly
> everything exceeding basic labels etc.) and doing that might be non
> trivial and error prone. Just imagine the different programming concepts
> involved with treeviews/listviews in different toolkits like GTK+, MS
> Forms, Swing and Qt. These are rather basic widgets, you would need to
> do this for the concept to be useful.
> 
> You would have to find some kind of a meta-model programming style to
> cover rather primitive listviews like those in Qt and rather
> sophisticated like in Swing.
> 
> In my experience GUI toolkits don't just differ in the way they name
> things but also in basic concepts.
> 
> mfg
> Martin
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list

-- 
Richard Hendershot <rshendershot@mchsi.com>

--=-SR+wER9xQF6HY11cmk5k
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
 <META NAME="GENERATOR" CONTENT="GtkHTML/3.1.14">
</HEAD>
<BODY>
On Sun, 2004-07-11 at 14:33 +0200, Martin Probst wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Am So, den 11.07.2004 schrieb Payton Byrd um 14:21:
&gt; I think that using namespaces fixes the problems described. You have a
&gt; basic namespace for &quot;standard&quot; widgets such as buttons and labels, and
&gt; then each targeted widget would reside in a targeted namespace.

Yes that would fix it. But without being to negative I think this would
result in a very limited set of widgets (see xhtml+css). This would
massively limit the possibilities of the developer.
</PRE>
</BLOCKQUOTE>
if each namespace represented a meta-tag that mapped to implementation-specific complexity, perhaps the namespaces could be grouped to represent &quot;shelles&quot; of dependancy.&nbsp; eg.&nbsp; LCD is the basic piece and each shell builds on that.&nbsp; Toolkits can be members of each namespace.&nbsp; So, if my toolkit chose getLabel or toText or whatever, being a member of the TO-TEXT attribute of whatever meta-tag holds label info...&nbsp; well, then it would be available in a concrete form at runtime. 
 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>

<FONT COLOR="#000000">&gt; In the case of Microsoft, they probably won't</FONT>
<FONT COLOR="#000000">&gt; support GTK widgets directly, but that doesn't mean you cannot create a</FONT>
<FONT COLOR="#000000">&gt; user control to implement a GTK widget and then map that widget's</FONT>
<FONT COLOR="#000000">&gt; namespace node to your user control when the XML is parsed to the native</FONT>
<FONT COLOR="#000000">&gt; language.</FONT>

Would you parse the XML and translate it before shipment or on the
client? In the first case this could be possible, but in the latter it
would result in the complexity problems I described below.

These mappings would have to be done for a lot of widgets (nearly
everything exceeding basic labels etc.) and doing that might be non
trivial and error prone. Just imagine the different programming concepts
involved with treeviews/listviews in different toolkits like GTK+, MS
Forms, Swing and Qt. These are rather basic widgets, you would need to
do this for the concept to be useful.

<FONT COLOR="#000000">You would have to find some kind of a meta-model programming style to</FONT>
<FONT COLOR="#000000">cover rather primitive listviews like those in Qt and rather</FONT>
<FONT COLOR="#000000">sophisticated like in Swing.</FONT>

<FONT COLOR="#000000">In my experience GUI toolkits don't just differ in the way they name</FONT>
<FONT COLOR="#000000">things but also in basic concepts.</FONT>

<FONT COLOR="#000000">mfg</FONT>
<FONT COLOR="#000000">Martin</FONT>

<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">Monodevelop-list mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:Monodevelop-list@lists.ximian.com">Monodevelop-list@lists.ximian.com</A></FONT>
<FONT COLOR="#000000"><A HREF="http://lists.ximian.com/mailman/listinfo/monodevelop-list">http://lists.ximian.com/mailman/listinfo/monodevelop-list</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Richard Hendershot &lt;<A HREF="mailto:rshendershot@mchsi.com">rshendershot@mchsi.com</A>&gt;
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-SR+wER9xQF6HY11cmk5k--