From jeff at bioinformatics.org  Sat Sep  1 01:17:21 2001
From: jeff at bioinformatics.org (J.W. Bizzaro)
Date: Fri Feb 10 19:20:53 2006
Subject: [Pipet Devel] berlin chat
Message-ID: <3B906F61.67BCB2A7@bioinformatics.org>

Attached is the log of an IRC chat I just had with a couple Berlin (windowing
system based on C++ and CORBA) developers.  Jeff
-------------- next part --------------
--> bizzaro (jwbizzaro@boston-port110.geoserve.net) has joined #berlin
--- Topic for #berlin is Berlin UI system (not about the city) | debian packages http://people.debian.org/~waldi/berlin/ and http://incoming.debian.org/
--- Topic for #berlin set by waldi at Thu Aug 30 14:12:48 2001
<bizzaro> Maybe it's a bad topic to bring up (maybe you guys don't want to deal with it, or maybe you've been asked too many times), but I'm curious about Berlin's plan for a desktop.
<bizzaro> Searching your site, I saw ref to Moscow, but not much else is said about it.
<bizzaro> I'm also under the impression that desktops like GNOME, KDE, CDE, etc. won't do, since they use X-specific widget sets.
<njs> bizzaro: it's a hard question to answer.
<njs> bizzaro: Berlin's goal at the moment is to get decent support for Text and Widgets; what sort of desktop will be built on top of things is a bit in the future
<bizzaro> njs: I happen to be the coordinator of a new desktop project looking for a windowing environment (X may not work well for what we want to do): http://bioinformatics.org/piedpiper/
--> sparq (russell@209-6-190-223.c3-0.wth-ubr2.sbo-wth.ma.cable.rcn.com) has joined #berlin
<bizzaro> njs: As you can see from the screenshots, we need fast drawing (lines, shapes) on the root window, we need to place an program window nested at any depth in the window of another, and we need to treat icons as window "bars".
<BenB> bizzaro: I am always confused about what people mean with "desktop".
<BenB> it is the taskbar/panel (wm-helper), compound document architecture or a set of applications written under the same syle guides?
<sparq> or a tower knocked onto it
<BenB> or something else?
<sparq> 's side
<sparq> I think it's one of those "sloppy" terms that really means "whatever get's tossed into this particular package."
<BenB> bizzaro: it doesn't seem like something that Berlin can't do, but I didn't completely underatdn you.
<bizzaro> Yeah, I personally think GNOME and KDE are a bit beyond the minimum required for a "desktop".
<bizzaro> Pied Piper may be considered a desktop in that it goes a little beyond a windowing system.
<BenB> bizzaro: so, piper is about how apps work together?
<bizzaro> Basically, it is a cross between a window manager and a flow chart drawing program like Dia.
<bizzaro> BenB: Yes, Piper, the program underneath Pied is a peer-to-peer networking environment which allows UNIX CLI programs to be piped over the Internet.
<bizzaro> We use CORBA, DOM, C++ and all that warm and fuzzy stuff to :-)
<BenB> bizzaro: heh
<bizzaro> The idea is to make a GUI which more accurately resembles the CLI, one which uses the UNIX paradigm of piping small tools to do complex things.
<BenB> bizzaro: yeah, I got that.
<BenB> bizzaro: nice idea.
<bizzaro> We consider GNOME et al to be Win/Mac clones.
<BenB> bizzaro: I assume you saw those "zooming" UIs, where you lay documents on the desktop and apps as "filter" over them?
<BenB> bizzaro: nod
<BenB> bizzaro: they are, mostly
<bizzaro> Right now we're using the GNOME canvas for drawing and windowing, but we can't imbed straight X apps in our "windowlets".
<bizzaro> zooming UIs <- where?
<BenB> bizzaro: you read our arch docs? you can mix drawing (vectors) and apps (widgets).
<BenB> bizzaro: I don't remember where I read about zooming UIs, letme look up my bookmarks.
<njs> BenB: they're really the same thing :-)
<bizzaro> BenB: Yes, combining vector drawing with widgets is appealing.  And the "zooming" sounds interesting.
<BenB> bizzaro: well, the zooming UI is not the UI approach Berlin will ship with by default.
<BenB> but as you saqy this, I probably read about it on the berlin list. searching there...
<njs> I struggled valiantly to categorize them for a while, then just gave up...
<bizzaro> BenB: From the sound of it, "zooming" seems limited to filtering one pipe.  Is that right?
<BenB> bizzaro: "zooming" was just one of 4 ascpets of the UI.
<BenB> bizzaro: I think, tehy had a solution for that, but I don't remember
<bizzaro> BenB: Is it something built into Berlin?
<BenB> bizzaro: it was a scientific document, like a master thesis or similar. all well thought-out.
<BenB> bizzaro: no, not related.
<BenB> bizzaro: but of course, berlin can zoom :)
<bizzaro> What does Berlin do about "window managers"?
<BenB> njs: you don't remember it anymore either, do you? i thought, somebody posted a link to it on berlin-design. within the last year, IIRC.
<BenB> bizzaro: almost nothing currently.
<njs> BenB: I remember it, but I don't rememeber the url
<bizzaro> BenB: Is there a plan to have a default WM?
<njs> bizzaro: supposedly, it has a DesktopKit, which is a dynamically loaded library that implements an API for things like "drawing window decorations"
<BenB> bizzaro: it has "top-level windows" (as other guis would call it), which the user can move around.
<BenB> njs: you don't remember anything that could help? like a more exact time of the post or a keyword?
<bizzaro> And can Berlin permit a WM to manage "windows-in-windows"?
<njs> bizzaro: hrm.  dunno what you mean.
<bizzaro> E.g., X WMs only manage the top level windows.
<njs> bizzaro: but the Berlin architecture is very homogenous.  A window is just a Graphic that you've embedded inside some window decorations
<bizzaro> Windows in windows don't use the WM.
<bizzaro> Let's say for example that Window3 is inside of Window2, which is inside of Window1...
<bizzaro> Can I then launch a program and have it run in Window3?
<bizzaro> Even though Window3 belongs to another program?
<njs> bizzaro: umm, sure, if you tweak the scene graph correctly
<njs> bizzaro: probably you'd want cooperation from the DesktopKit, so that when your program runs, it embeds it in Window3, rather than embedding it in the global Desktop
<bizzaro> Is this something the DesktopKit can currently do?
<njs> bizzaro: well, it could if you rewrote the DesktopKit::shell() implementation
<bizzaro> njs: Also, do you know if X is capable of this or not? (sorry for asking an X question here)
<njs> bizzaro: not a clue.  considering how little success I've had with "swallowed" apps in the past, I'll make a guess that it's not easy.
<bizzaro> njs: Reg rewriting DesktopKit::shell(), would this be a major overhaul or an added feature?
<BenB> bizzaro: embedding apps into others is trivial in berlin.
<BenB> bizzaro: check out the Fresco tutorial, Fdraw app screenshot.
<BenB> on Docs page
<bizzaro> BenB: Then DesktopKit::shell() wouldn't have to be rewritten?
<njs> bizzaro: well, the current shell() implementation is ~60 lines, all of which is simply creating close button, creating resize thumbs, etc.
<njs> bizzaro: the way Berlin works right now:  an application instantiates various instances of (subclasses of) the class Graphic, then puts them together.  Basically you end up with a tree of Graphics, with each Graphic conceptually subsuming all its children
<njs> bizzaro: so then when the application wants to create a top-level window, it calls DesktopKit::shell(top_level_graphic), and shell() wraps top_level_graphic up in a few decorators graphics and inserts the whole thing in a special "Desktop" graphic that allows arbitrary positioning of children
<BenB> bizzaro: probably, you won't use DesktopKit, because it works like conventional desktops - apps have no relation to each other.
<bizzaro> BenB: What would you suggest?
<njs> bizzaro: oh, are these applications written especially for this interface?
<BenB> bizzaro: rather, you'd create a PipeKit or similar, which could hook 2 or more apps up, and would also represent that graphically.
<BenB> bizzaro: I guess so. how would they otherwise exchange (stream) data?
<bizzaro> njs: We'd like any application to be embedded in a windowlet, but most will be defined via XML.
<njs> BenB: dunno, I don't know what he actually want's :-)
<BenB> njs: a graphical equivalent to the shell pipes. see the scrrenshots on the page he gave in the beginning.
<bizzaro> BenB: The interfaces are abstracted from the actual apps.  It's very much like HTML forms for CGI.
<bizzaro> BenB: The CGI-like programs being the CLI programs.  BUT we would like native GUI apps to be embedded.
<njs> bizzaro: for native gui apps, just change shell() so it sticks new top level windows where you want them, rather than at the top level
<BenB> njs: I'm quite sure that link wasn't there, when I tried to remove the page, because I checks the links page (and reloaded)
<bizzaro> njs: Would changes to shell() require users to run a patched version of Berlin?
<njs> bizzaro: they'd need a different DesktopKit where the server could find it.
<njs> bizzaro: the DesktopKit, like other kits, is dynamically loaded at runtime anyway.
<BenB> njs: that's the page I used too, I think.
<bizzaro> njs: So, Pied Piper would have to provide "PiperKit" as a plugin?
<njs> bizzaro: yes.
<BenB> bizzaro: which the server would have to advertize, at least.
<BenB> bizzaro: so apps find it.
<BenB> (if it doesn't even run in the server directly)
<njs> bizzaro: you'd drop the PiperKit somewhere in the server's plugin search path, and then app's connecting to the server would be able to request it (and get an error if it didn't exist)
<BenB> bizzaro: I didn't get your "abstracted" and "CGI" stuff
<bizzaro> BenB: Don't understand the analogy?
<njs> bizzaro: yes, BenB also has weird ideas about allowing for this to happen without having it be a shared library loaded by the server, but rather a separate process :-)
<BenB> bizzaro: don't understand what you mean.
<njs> bizzaro: (which is really pretty easy -- you could have the PiperKit be its own process without much difficulty)
<BenB> njs: rebel me ;-P
* BenB running around with a greenpeace flag
<bizzaro> BenB: Each program on the PiperNet has an XML document associated with it as meta-data.  This document describes the placement of widgets to the Pied desktop.
<bizzaro> BenB: Something like GLADE XML.
<BenB> bizzaro: who creates that document? the user or the app developer?
<bizzaro> BenB: Piper starts with a template document, which is then embellished by the user, who can also be considered a developer.
<BenB> I *still* get sircam worms.
<BenB> bizzaro: nope, the user is not a developer :-)
<BenB> bizzaro: this a problem with your whoile idea btw - way too complicated for the normal user.
<bizzaro> BenB: The XML document is modified either through GUI widgets or via recombining nodes in the network.
<BenB> bizzaro: but don't let you stop by that :).
<BenB> bizzaro: ah, nod
<bizzaro> BenB: Nah, the nice part is that the network design can be hidden from the user, so the whole thing looks like a Mac desktop.
<bizzaro> BenB: The user becomes a developer simply by revealing the network details.
<bizzaro> BenB: So, the user can make changes, re-hide the network, and re-publish his changes.
<BenB> bizzaro: yes.
<BenB> bizzaro: so, a browser would be a http "document" (-> binary stream) plus a html parser "filter" (->dom) plus a html renderer filter?
<bizzaro> BenB: In any case, we're really targeting scientific and technical users.
<BenB> bizzaro: with all that being hidden by default, i.e. a web browser is just a predefined combination of the components?
<njs> BenB: perhaps ->sax, for an actually streamable parse format...
<njs> bizzaro: doesn't IBM have a visualization toolkit along these lines?
<bizzaro> BenB: Yes, I think you've got the idea :-)
<bizzaro> njs: OpenDX: http://www.phys.ocean.dal.ca/docs/DX-pics/program.gif
<njs> bizzaro: right, that
<bizzaro> njs: Main page: http://www.opendx.org/
<bizzaro> njs: But you can see from the OpenDX screenshot, that it is far from being a desktop.
<njs> bizzaro: right
<bizzaro> njs: Piper also has better P2P facilities.
<bizzaro> njs: DX wasn't meant to be P2P or a desktop.
<njs> bizzaro: your program model doesn't seem terribly general, though -- it seems like most GUIs aren't pipelines
<BenB> njs: depends on how you design them
<BenB> njs: a mailer could be an IMAP document plus a filter filter plus a MIME-decode filter plus the html parser etc.
<BenB> njs: of course the GUi would look rather different then :)
<bizzaro> njs: Right, most GUI apps aren't.  We're mostly after CL programs and ones made for Piper.  As for existing GUIs, we can put the document saved (using File->Save in any GUI) into the workflow.
<bizzaro> njs: Back to the shell() function.  If we made PipeKit, would each application have to call it specifically?
<njs> bizzaro: shell() is the right place to catch non-piper applications, and embed them visually
<njs> bizzaro: if an application wants to do Piper specific stuff, then it should use the Piper API, as provided by the PiperKit...
<bizzaro> njs: Okay, got it.
<bizzaro> I'll talk this over with some of the other developers.
<bizzaro> Berlin make work very well for us.
<bizzaro> Also, please consider Pied Piper if Berlin is considering endoursing a desktop project.
<bizzaro> You can reach me at jeff@bioinformatics.org
<njs> bizzaro: it's a bit early for Berlin to consider anything about desktop projects :-)
From jeff at bioinformatics.org  Sat Sep  1 18:43:54 2001
From: jeff at bioinformatics.org (J.W. Bizzaro)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] libflow
Message-ID: <3B9164AA.9E493288@bioinformatics.org>

I fixed the previous problem by adding the path in the Makefiles.

Then I get this error:

-----------------------------------
...
gcc -shared -o vflowmodule.so -Wl,--rpath
-Wl,`/opt/overflow/bin/overflow-config libflow --libs`  mod_vflow_wrap.o
-L/usr/lib -lxml -lz                          -lstdc++  -lpthread 
/usr/local/bin/ld: cannot find -lflow
-----------------------------------

Testing the overflow-config command...

-----------------------------------
$ /opt/overflow/bin/overflow-config libflow --libs
-L/opt/overflow/lib -lflow
-----------------------------------

Okay...

-----------------------------------
$ ls -l /opt/overflow/lib
total 16071
16070 -rwxr-xr-x    1 root     root     16389193 Sep  1 02:28 libflow-0.6.so*
    1 -rwxr-xr-x    1 root     root          655 Sep  1 02:28 libflow.la*
    0 lrwxrwxrwx    1 root     root           14 Sep  1 02:28 libflow.so ->
libflow-0.6.so*
-----------------------------------

Seems to be there, right?

Also...

-----------------------------------
$ ldconfig -p | grep libflow
	libflow.so (libc6) => /opt/overflow/lib/libflow.so
	libflow-0.5.so (libc6) => /opt/overflow/lib/libflow-0.5.so
-----------------------------------

What's wrong?

Jeff
-- 
J.W. Bizzaro                                jeff@bioinformatics.org
Director, Bioinformatics.org        http://bioinformatics.org/~jeff
"As we enjoy great advantages from the inventions of others, we
should be glad of an opportunity to serve others by any invention
of ours; and this we should do freely and generously."
                   -- Benjamin Franklin
--


From jean-marc.valin at hermes.usherb.ca  Sat Sep  1 21:14:55 2001
From: jean-marc.valin at hermes.usherb.ca (jean-marc.valin@hermes.usherb.ca)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] libflow
In-Reply-To: <3B9164AA.9E493288@bioinformatics.org>
References: <3B9164AA.9E493288@bioinformatics.org>
Message-ID: <999393295.3b91880f9330c@imp.usherb.ca>

Looks like a version mismatch. At some places, it's libflow-0.6.so and at some
other places it libflow-0.5.so. You may have two versions conflicting. BTW,
libflow-0.6 means that you got a recent CVS version (0.6.0 is not yet released).
Please update it, as there have been a couple instabilities this week (it's
fixed now).

I suggest you make sure you don't have any Overflow rpm installed and then "rm
-rf /opt/overflow". Also, as I told you it's now recommended to install Overflow
with prefix=/usr /usr/local or /opt  The conflicting include problem is now
solved. The includes are now in $(prefix)/include/overflow instead of just
$(prefix)/include.

     Jean-Marc


From jeff at bioinformatics.org  Sat Sep  1 23:07:31 2001
From: jeff at bioinformatics.org (J.W. Bizzaro)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] libflow
References: <3B9164AA.9E493288@bioinformatics.org> <999393295.3b91880f9330c@imp.usherb.ca>
Message-ID: <3B91A273.727D8D7E@bioinformatics.org>

I updated ldconfig so that it recognizes libflow-0.6 and then tried compiling
Piper again, but I got the same error.

Also, I do have the very latest Overflow source from CVS.

I'm going to retry installing Overflow, but in /usr.

Jeff

jean-marc.valin@hermes.usherb.ca wrote:
> 
> Looks like a version mismatch. At some places, it's libflow-0.6.so and at some
> other places it libflow-0.5.so. You may have two versions conflicting. BTW,
> libflow-0.6 means that you got a recent CVS version (0.6.0 is not yet released).
> Please update it, as there have been a couple instabilities this week (it's
> fixed now).
> 
> I suggest you make sure you don't have any Overflow rpm installed and then "rm
> -rf /opt/overflow". Also, as I told you it's now recommended to install Overflow
> with prefix=/usr /usr/local or /opt  The conflicting include problem is now
> solved. The includes are now in $(prefix)/include/overflow instead of just
> $(prefix)/include.
> 
>      Jean-Marc
> 
> _______________________________________________
> pipet-devel maillist  -  pipet-devel@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/pipet-devel

-- 
J.W. Bizzaro                                jeff@bioinformatics.org
Director, Bioinformatics.org        http://bioinformatics.org/~jeff
"As we enjoy great advantages from the inventions of others, we
should be glad of an opportunity to serve others by any invention
of ours; and this we should do freely and generously."
                   -- Benjamin Franklin
--


From jeff at bioinformatics.org  Sun Sep  2 19:26:01 2001
From: jeff at bioinformatics.org (J.W. Bizzaro)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] error in net_types.h
Message-ID: <3B92C009.17DCE81A@bioinformatics.org>

Jean-Marc,

I installed Overflow in /usr and got past the previous error, but now I get
the following:

--------------------------------------------------------
gmake[2]: Entering directory
`/usr/home/jeff/piper-2001/piper-0.0.2-test1/piper-20010902-inst/bl/plugins'
c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I../include
-I/opt/omniORB_300/include -g -ggdb -D__x86__ -D__linux__ -Wall -I../src 
-I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/glib/include
-I/usr/include/gnome-xml `overflow-config libflow --cflags`    -g -O2 -c
plugin_sensor_PL_main.c
In file included from /usr/include/overflow/ObjectRef.h:9,
                 from plugin_sensor_PL_main.c:17:
/usr/include/overflow/net_types.h:228: type specifier omitted for 
parameter
/usr/include/overflow/net_types.h:228: parse error before `&'
/usr/include/overflow/net_types.h:228: `operator>> (...)' must have an 
argument of class or enumerated type
/usr/include/overflow/net_types.h:228: `operator>> (...)' must take 
exactly two arguments
/usr/include/overflow/net_types.h:230: type/value mismatch at argument 
1 in template parameter list for `template <T> struct TypeTraits'
/usr/include/overflow/net_types.h:230:   expected a type, got `String'
/usr/include/overflow/net_types.h:230: explicit specialization of 
non-template `{anonymous struct}'
gmake[2]: *** [plugin_sensor_PL_main.o] Error 1
------------------------------------------------------

Jeff
-- 
J.W. Bizzaro                                jeff@bioinformatics.org
Director, Bioinformatics.org        http://bioinformatics.org/~jeff
"As we enjoy great advantages from the inventions of others, we
should be glad of an opportunity to serve others by any invention
of ours; and this we should do freely and generously."
                   -- Benjamin Franklin
--


From jeff at bioinformatics.org  Fri Sep  7 07:24:11 2001
From: jeff at bioinformatics.org (J.W. Bizzaro)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] JM: error in net_types.h
Message-ID: <3B98AE5B.7019D439@bioinformatics.org>

(repost)

Jean-Marc,

I installed Overflow in /usr and got past the previous error, but now I get
the following:

--------------------------------------------------------
gmake[2]: Entering directory
`/usr/home/jeff/piper-2001/piper-0.0.2-test1/piper-20010902-inst/bl/plugins'
c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I../include
-I/opt/omniORB_300/include -g -ggdb -D__x86__ -D__linux__ -Wall -I../src 
-I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/glib/include
-I/usr/include/gnome-xml `overflow-config libflow --cflags`    -g -O2 -c
plugin_sensor_PL_main.c
In file included from /usr/include/overflow/ObjectRef.h:9,
                 from plugin_sensor_PL_main.c:17:
/usr/include/overflow/net_types.h:228: type specifier omitted for 
parameter
/usr/include/overflow/net_types.h:228: parse error before `&'
/usr/include/overflow/net_types.h:228: `operator>> (...)' must have an 
argument of class or enumerated type
/usr/include/overflow/net_types.h:228: `operator>> (...)' must take 
exactly two arguments
/usr/include/overflow/net_types.h:230: type/value mismatch at argument 
1 in template parameter list for `template <T> struct TypeTraits'
/usr/include/overflow/net_types.h:230:   expected a type, got `String'
/usr/include/overflow/net_types.h:230: explicit specialization of 
non-template `{anonymous struct}'
gmake[2]: *** [plugin_sensor_PL_main.o] Error 1
------------------------------------------------------

Jeff
-- 
J.W. Bizzaro                                jeff@bioinformatics.org
Director, Bioinformatics.org        http://bioinformatics.org/~jeff
"As we enjoy great advantages from the inventions of others, we
should be glad of an opportunity to serve others by any invention
of ours; and this we should do freely and generously."
                   -- Benjamin Franklin
--


From jean-marc.valin at infospace.com  Fri Sep  7 10:01:56 2001
From: jean-marc.valin at infospace.com (Jean-Marc Valin)
Date: Fri Feb 10 19:20:54 2006
Subject: [Pipet Devel] JM: error in net_types.h
References: <3B98AE5B.7019D439@bioinformatics.org>
Message-ID: <3B98D354.B998B3E0@infospace.com>

> I installed Overflow in /usr and got past the previous error, but now I get
> the following:

I suggest you try removing the:
_DEF_OBJECT_TYPE(String)

It worked for Jarl. This problem is really wierd. It doesn't show up on
any of my box or Dominic's (It works on Mdk 7.0, 7.2, 8.0 & RH 7, 7.1 &
solaris x86, ...). What version of gcc are you using (on which distro?)?
Also, could you send me the pre-processed output (using the gcc -E flag)
so I can have a look at it?

	Jean-Marc