sbazgui

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

sbazgui

Judson, Ross
...provides a simple GUI to some of sbaz's functionality (thanks to Lex
for a clean library -- I did not have a single problem while putting
sbazgui together.

sbaz install sbazgui

...will give you 0.1, and make it exceptionally convenient for you to
stay up to date.  Note that I have only tested on XP so far; I'll have
to get some Linux installed and see what happens -- it should be OK, as
it is quite "vanilla".  Note that sbazgui looks particularly good if you
have the Substance Look and Feel installed as a Java extension.  

Start it with "sbazgui", and ignore the ugly console junk that will be
gone by 0.2 ;)  The first time you run you'll be asked to find your sbaz
directory (mine is d:\scala-2.1.0); that value is stored with Java's
preferences facility.

sbazgui always retrieves the latest package list on startup, shows you
what you have installed, and where you can update.  It can install
individual packages, update them, or upgrade all (corresponding to sbaz
commands).  The gui clears away some of the version information so you
can see what you have, and what the latest version is.

sbazgui took about six hours (including sbaz packaging) to write in
Sean's Eclipse environment, and a good part of that was spent on trying
various forms of Scala syntax to handle common GUI issues.  All in all,
it's going to be depressing the next time I write GUI code in
Java...I've got premonitions of irritation already.  ;)

Once you get the feel of the language _and the type system_, Scala's "it
just works" factor starts to escalate rapidly.  

Some things I particularly liked:

def loadNews = busyThread {
  val rss = xml.XML.load(new
java.net.URL("http://scala.epfl.ch/rss.xml").openStream());
  val html = (rss \\ "item" \ "description").foldLeft(
        new Stringer("<html><body style='font-size:small;
font-family:sans-serif'>"))(
          (sb,d) => sb + repl(d.text, "<div>", "", "</div>", "","<hr
/>", "","<p />", "<br>","<br />", "<br>") + "<hr>") +
            "</body></html>";
    swing { news.text = html.toString; news.root.setCaretPosition(0) }
}

That bit of code drops into a worker thread, sets up a wait cursor,
reaches out to the Scala web site, pulls down the RSS feed, parses it
into XML, does xpath across the XML to extract news article
descriptions, chops them up into HTML more to Swing's liking, hops back
to the swing thread to insert the text into a news pane, puts back the
normal cursor, and ends the thread.

All in all, not bad for 8 lines of code -- and it could have been less.
;)

This declares a button and sets up a handler:

  val upgradeButton = new SButton("Upgrade All")({updateAll})

I assemble GUI elements like this:

 val main = new SPanel().inset(4) + North(titlePanel) + West(newsPanel)
+ Center(new SScrollPane(table))
  val time = new SLabel("<time>").etched
  val status = new SLabel("<Status>").etched
  this + South(new SPanel().inset(4) + West(time) + East(status)) +
Center(main)

Again, very concise but readable syntax.  When I pull away the library
code, sbazgui is only 220 lines of code.  

RJ
Reply | Threaded
Open this post in threaded view
|

Re: sbazgui

Lex Spoon
This looks really great, Ross!  It is fun having a nice-looking GUI
app on the bazaar.

By the way, there is a scala.home property that gets set automatically
for you.  It points to the sbaz directory that the program is run out
of.  All (sbaz-based) programs can use this to find any other files
you need.  For sbazgui in particular, you can use it as the default
sbaz directory to manage.


Do you intend to tinker on sbazgui any more?


-Lex

Reply | Threaded
Open this post in threaded view
|

RE: Re: sbazgui

Judson, Ross
In reply to this post by Judson, Ross
There are quite a few things I'd like to add...

- change/handle multiple sbaz directories and switch between them
- auto-create "news" of new/change packages
- sorting/filtering
- categories (I'd like to see sbaz support a notion of nested categories
-- we'll need it sooner or later)
- automatic filtering out of placeholders unless they can be removed
- "peek" feature shows contents/structure of selected package
- click on Scala logo goes to the website
- tooltips for everything
- right-click context menus
- prefs for window size/position
- Substance look and feel, if available
- move GUI classes to a private package so they don't interfere with
other stuff
- "helper" mode (glass pane superimposes semi-transparent tooltips) on
startup

From sbaz, I'd like to see a "compile from source" command/standard (and
accompanying meta description for packages), and support for nested
categories.

I like the way the CygWin installer lets you see what's available,
auto-install groups, etc...that's probably the direction we should move.

RJ


-----Original Message-----
From: news [mailto:[hidden email]] On Behalf Of Lex Spoon
Sent: Tuesday, April 04, 2006 12:22 PM
To: [hidden email]
Subject: Re: sbazgui

This looks really great, Ross!  It is fun having a nice-looking GUI app
on the bazaar.

By the way, there is a scala.home property that gets set automatically
for you.  It points to the sbaz directory that the program is run out
of.  All (sbaz-based) programs can use this to find any other files you
need.  For sbazgui in particular, you can use it as the default sbaz
directory to manage.


Do you intend to tinker on sbazgui any more?


-Lex

Reply | Threaded
Open this post in threaded view
|

Re: sbazgui

Lex Spoon
"Judson, Ross" <[hidden email]> writes:

> There are quite a few things I'd like to add...
>
> - change/handle multiple sbaz directories and switch between them
> - auto-create "news" of new/change packages
> - sorting/filtering
> - categories (I'd like to see sbaz support a notion of nested categories
> -- we'll need it sooner or later)
> - automatic filtering out of placeholders unless they can be removed
> - "peek" feature shows contents/structure of selected package
> - click on Scala logo goes to the website
> - tooltips for everything
> - right-click context menus
> - prefs for window size/position
> - Substance look and feel, if available
> - move GUI classes to a private package so they don't interfere with
> other stuff
> - "helper" mode (glass pane superimposes semi-transparent tooltips) on
> startup

All very cool stuff.  Also, do not forget feature completeness.  If
the GUI only offers a subset of the available functionality, then
there is a limit on where it is useful.  Browsing through all the
"help" documentation for the command line is probably worthwhile.


>
> From sbaz, I'd like to see  [...snip...] support for nested
> categories.

Sure.  I'll put that on the list....


>
> I like the way the CygWin installer lets you see what's available,
> auto-install groups, etc...that's probably the direction we should move.
>

Actually, package groups are already present on one form.  An example
is the package named "scala".  It contains no files itself, but it
depends on all the development-tool packages.


-Lex

Reply | Threaded
Open this post in threaded view
|

source packages (Re: sbazgui)

Lex Spoon
In reply to this post by Judson, Ross
> From sbaz, I'd like to see a "compile from source" command/standard (and
> accompanying meta description for packages)


This is not as trivial as it sounds.  The current strategy, at least
for the scala-dev bazaar, is that people post built, ready-to-run
packages.  If a built package is broken with respect to other packages
on the bazaar, then one package or the other needs to be fixed.


The main advantage to compiling sources is that Scala source is more
compatible than the resulting .class files.  That is, interfaces can
stay compatible even though the .class files change in incompatible
ways.  Distributing in source would increase the likelihood of two
packages being able to be used together.

Have I missed another advantage?

There are a number of negative issues that seem to outweigh this
benefit.  Here are some that come to mind.



First, build dependencies are much larger than install dependencies.
Consider things like ant, ant-contrib, javac, perl, python, scsh,
automake, jam, etc.  If we build at the installation sites, then we
have to figure out a way to ensure that installation sites have all of
these extra dependencies.  The dependencies either need to be on the
bazaar, or we need to tell people that they must have them installed
separately before they can build packages.

This problem is compounded by build dependencies being difficult to
work out accurately anyway.  Speaking from experience with Debian
packages, it is very easy to overlook things like using the "tree"
utility or depending on "bash" when you meant to depend only on "sh".


Both answers to "should we automatically compile at install time" give
bad results.  If we say yes, then install times become much slower.
To contrast, if we do not build-at-install, then what hope do we have
of getting the build-time install scripts working correctly for each
package?  Untested code is broken code.

Compilation is not perfectly deterministic once you take into
consideration all the build dependencies.  If we compile-at-install
time, then people will be installing code that is not exactly the same
code the developer tested.



As an alternative, I have thought about addressing this tradeoff by
using a multi-stage build process.  All code in packages would be pure
Scala code.  This approach would mean that we'd get the advantage of
source-code compatibility (the main reason I can think of to have
install-time building), while not having extra build dpeendencies like
ant.  However, as tempting as this is, notice that not all source code
can be converted to Scala code!  The Scala compiler, for example,
contains a small number of non-Scala files that simply cannot be
converted into Scala code.  Worse, some packages, e.g. junit and
servlet-api, are pure Java code!



Finally, to curtail one dead-end path, notice that source packages
never give the real source in practice.  The real source is in a CVS
or SVN repository somewhere.  If you want to hack on a project, don't
grab its source package--go to its web site and follow the directions
you see.  And if you don't want to hack, but instead just browse the
code, you should look at the /src hierarchy in your sbaz directory....


-Lex

Reply | Threaded
Open this post in threaded view
|

sbazgui

Judson, Ross
In reply to this post by Judson, Ross
For those who've tried it, if you use it to catch up to the latest scala
packages, could you let me know if it works for you, or if anything goes
wrong when you do the upgrade?

[hidden email]

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: sbazgui

Lex Spoon
"Judson, Ross" <[hidden email]> writes:
> For those who've tried it, if you use it to catch up to the latest scala
> packages, could you let me know if it works for you, or if anything goes
> wrong when you do the upgrade?

I have upgraded it a few times at this point via "sbaz upgrade" and it
always seems to keep chugging along just great!  I am usually thinking
of upgrading something else when I do it, and happen to notice that
there is a new sbazgui version coming down along with it.  Cool!

-Lex