You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Philippe Lhoste <Ph...@GMX.net> on 2011/01/27 22:02:29 UTC
Pivot, Scala, Gradle, Life, the Universe and Everything
Yes, I am re-reading Douglas Adams' works...
I am back!
Well, I suppose nobody remembers me, as I haven't done anything
remarkable for Pivot and my presence on this list hasn't be very long.
Time of a hacker is alas limited, particularly with a work and a family...
I deepened my knowledge of JavaFX (in vain... but well, I learned some
things about animation and such, and had fun); also had some activity on
Processing forum; I learned to use Gradle, to compile the small Scala
programs I am making as I learn also the language.
All this is deeply uninteresting, I guess. Except, that I wanted to make
some GUIs with Scala, and the announcement of the version 2.0
(congratulations!) reminded me of Pivot (well, I never really forgot it,
just put it aside).
So as a warm up, I started to rewrite the tutorial code in Scala (I
think I saw this suggested some time ago in the list).
Progress is a bit slow, but some initial success show I am on the right
way. The curious can take a look at my repository, work in progress:
http://bazaar.launchpad.net/~philho/+junk/Scala/files/head:/PivotTutorials/
Note: I have put neither the Apache license nor mine (a simple
zlib/libpng one) as header of the files, not sure what is appropriate. I
made my own package, to make clear this is not done by Apache.
If you have any remark on this, I have no problem to change that.
So, with Gradle, I can easily compile the Scala code and run it. At
least run the HelloJava code (renamed HelloScala, of course) and the
HelloBXML.
I can compile the code I made in the Text folder, but I failed to run it.
Basically, I run the org.apache.pivot.wtk.ScriptApplication class with
the parameter -src=path/to/text/text_inputs.bxml with the classpath set
to the runtime classpath (the same used to run the pure class files) and
the resource files (BXML and others) copied at the same place.
But the ScriptApplication fails to find the BXML file.
Note: I am on Windows, tried on XP and on 7.
The issue probably comes from the fact the class uses a classloader to
find the resource, I am not too sure how it handles Windows paths. Of
course, I changed the backslashes to slashes. I also tried to prepend a
slash to the absolute path of the file (I am intrigued by the
substring(1) in the getResource() call), I tried various relative paths,
no success.
With an absolute path, I get an error like:
java.lang.IllegalArgumentException: Cannot find source file
"H:/PhiLhoSoft/Scala/PivotTutorials/bin/classes/main/org/philhosoft/pivot/tutorials/text/text_inputs.bxml".
at
org.apache.pivot.wtk.ScriptApplication.startup(ScriptApplication.java:47)
at
org.apache.pivot.wtk.DesktopApplicationContext$2.run(DesktopApplicationContext.java:594)
at
org.apache.pivot.wtk.ApplicationContext$QueuedCallback.run(ApplicationContext.java:1474)
at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
and a Pivot window opens, showing the same message in a dialog box.
So, basically, my question is: what path to use as argument here, on
Windows? (I found that a Linux user used an absolute path, so it seems
mostly OK, no?)
Oh, on an unrelated note: in the past, I had no problems to run Pivot
demos (on XP), it loaded fast and was displayed nicely.
I wanted to follow the tutorial online, and the Sample Application demo
shown the Java wait logo for quite some time (several minutes, I would
say), then a black area where the applet should be. Nothing in the Java
Console, and actually it closed as if the applet crashed.
On next pages, I had the same black area. Then on the Text Areas page, I
got a correct applet! (Windows XP Pro SP3, Java 1.6.0_23, Firefox 3.6)
At home, on my Win7 box, I tried again, and got the same problem. I
refreshed the page a couple of times and got the Sample
Application/Kitchen Sink running.
Mmm, tried again while writing this mail. First got a black applet, then
the app. Again, got a black applet only. Again, works fine!
Trying Color Scheme Builder, it works OK after accepting the security
warning (mmm, I can't type values in the spinners? Annoying, it is slow
to go to a value).
I haven't find something about this issue in the recent (January)
archive, so I thought I should mention it.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 28/01/2011 14:05, Greg Brown wrote:
>> Not sure how to do that with pure BXML files.
>
> You can't do it purely with BXML, but since you are using Scala, you
> must be writing classes anyways. Take a look at the Hello World
> tutorial for an example of implementing the Application interface.
Even with Scala, when we have a pure BXML, we want to be able to run it
directly, as we do in Java.
I think I made a mistake, taking the path a bit too high in the bin
folder, or something.
The Gradle task is:
task runB(type: JavaExec) {
description = 'To run the BXML scripts. Pass the name as
-Psample=text/text_inputs'
main = 'org.apache.pivot.wtk.ScriptApplication'
classpath = sourceSets.main.runtimeClasspath
args "--src=/${basePath}/${sampleName}.bxml"
}
and now it works well, both with pure BXML and those using some Java
(now Scala) classes.
>>> Could be a JVM issue. Might also be related to the use of a
>>> volatile image for buffering. Try setting
>>> -Dorg.apache.pivot.wtk.disablevolatilebuffer=false when you start
>>> your app.
>>
>> I wasn't clear, I think: the issues I saw was on the online demos,
>> the applets. And yes, it might be related to the version of Java I
>> use.
>
> No, you were clear - I just didn't think it through. Are you using a
> Dell by any chance? I think that some of the other users who have
> reported this issue were using Dell hardware.
Indeed a Dell computer at work (an old one) and a modern HP at home,
both with ATI cards (not the best ones...).
Making (slow) progress on converting tutorials. Of course, I skip the
pure BXML ones, as there is nothing to convert.
Just did the Localization one, I made a fr version while I was at it.
(Attached, feel free to use it.)
I have fun converting Java loops to Scala comprehensions, like
for (int i = 0; i < fonts.length; i++) {
if (fonts[i].canDisplayUpTo(sampleResource) == -1) {
theme.setFont(fonts[i].deriveFont(Font.PLAIN, 12));
break;
}
}
becoming
fonts find (_.canDisplayUpTo(sampleResource) == -1) foreach {
f => theme.setFont(f.deriveFont(Font.PLAIN, 12))
}
I had to ask help on the scala-user list for this one, as Scala doesn't
have break built in.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
>> Try using a path on the classpath, not a file system path. For example, --src=/com/foo/bar/my_file.bxml.
>
> Aha! Either I tried too high in the path, or I forgot the initial slash... But now it works, many thanks!
> Still curious: why the initial slash, if you skip it in the code? If I replace it with a ! it works as well...
Leading slashes are typically used to represent an "absolute" path, whereas the absence of a path implies "relative". Since the source path is absolute (it always begins at the root of the classpath), a leading slash is appropriate. The internal logic isn't strict though, so you can currently use any character.
>> OTOH, you may want to simply implement the Application interface
>> yourself rather than using ScriptApplication. For what you are trying to
>> do, I think it might be a better approach anyways.
>
> Not sure how to do that with pure BXML files.
You can't do it purely with BXML, but since you are using Scala, you must be writing classes anyways. Take a look at the Hello World tutorial for an example of implementing the Application interface.
>> Could be a JVM issue. Might also be related to the use of a volatile
>> image for buffering. Try setting
>> -Dorg.apache.pivot.wtk.disablevolatilebuffer=false when you start your app.
>
> I wasn't clear, I think: the issues I saw was on the online demos, the applets. And yes, it might be related to the version of Java I use.
No, you were clear - I just didn't think it through. Are you using a Dell by any chance? I think that some of the other users who have reported this issue were using Dell hardware.
G
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 27/01/2011 22:17, Greg Brown wrote:
> How you license (or not) your own code is up to you. If you
> modify/redistribute any of the Pivot source code, you'll need to retain
> the ASL header.
OK. In BXML, I just keep them as is, with just the package fix when
needed. In sources, I will put my header, mentioning the original Java
source.
> Try using a path on the classpath, not a file system path. For example, --src=/com/foo/bar/my_file.bxml.
Aha! Either I tried too high in the path, or I forgot the initial
slash... But now it works, many thanks!
Still curious: why the initial slash, if you skip it in the code? If I
replace it with a ! it works as well...
> OTOH, you may want to simply implement the Application interface
> yourself rather than using ScriptApplication. For what you are trying to
> do, I think it might be a better approach anyways.
Not sure how to do that with pure BXML files.
> Could be a JVM issue. Might also be related to the use of a volatile
> image for buffering. Try setting
> -Dorg.apache.pivot.wtk.disablevolatilebuffer=false when you start your app.
I wasn't clear, I think: the issues I saw was on the online demos, the
applets. And yes, it might be related to the version of Java I use.
> Spinners are not currently editable, though there is a JIRA ticket for this.
Still lot of work to do, I see... :-) Also noticed that text areas might
use a bit more shortcuts (Ctrl+Backspace/Del to delete words,
double-click to select a word, etc.).
Thanks!
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Superstring Media <su...@gmail.com>.
Hi all,
I agree, the importance of keeping configuration and code separate has become VERY important to me. This has lead me to having fewer objects that are capable of having more behaviours. The objects are injected with rules which capture all the non local variables. The rules are assembled into different configuration files (for graphic, sonic, tools, etc) which align with different related objects (contexts) and an object (or many objects at once) can instantly have their look, feel and behaviour changed just by activating different configuration/s.
I'm hoping that once these configurations are specified (a lot of work but at least they are soft-wired!) they will be loaded by Pivot into a configuration manager which is likely based on the Dictionary and binding components in the Pivot API. An important part of this is to have the ability to de/serialize JSON files in and out of the configuration manager at anytime (via user interaction). I'd be looking at a straight forward JSON API to help here or maybe BXML, although it looks like BXML may be to inflexible. I can see the purpose in using BXML to erect a UI or an object graph but then it seems unnatural to use it to update the erected structure. I'm still looking into what possible API might be most useful for this.
The way the configuration manager (with its contexts) works is similar to CSS where they provide rules that renderer objects in turn lookup by key selectors to change the graphic, sonic or other behaviour of the application. The keys work like an indirect binding system between the model and other objects and the rules they use. After working with music notation and many other music related aspects this is the system I came up with, not sure if this type of dependancy injection system has been developed elsewhere?
Here is a high level diagram of the core modules and their basic interaction:
To me what matters most is to define the app the way the features dictate, then if possible find an API that thinks along the same lines. Onwards then!
Thom
On 2011-01-29, at 1:27 PM, calathus wrote:
>
>
> On Sat, Jan 29, 2011 at 1:44 AM, Philippe Lhoste <Ph...@gmx.net> wrote:
> On 29/01/2011 10:26, calathus wrote:
> When we write GUI application in Java, the most important part is GUI
> application logic (description of user interaction), not layout.
> So we don't want to bother with layout in Java code level, also some GUI
> object should be determined by the data type used in the application.
> For instance, if type is boolean, we may want to map to check box etc.
> And if we want to change these data type, we should not have to modify
> the layout(most of case) file.
>
> I agree with most, but not all. I think all GUI should be described in separate files, indeed, with no logic in it (or, at best/worst, only code pertaining to GUI logic).
> But the leafs must be part of this description: if the type is boolean, the GUI designer can choose to implement it with radio buttons, combo box or even a list, if they need/want it. It is not a concern of the code.
>
> I think some missing ingredient here was the systematic default specification mechanism like CSS in HTML.
> If we start modifying layout for customized GUI object, the layout files are going to depend on data type.
> for instance, if the GUI object is specified as check box, and later the data type is changed to String or enumerated type, such GUI object is no longer appropriate. Or we may need to go through all layout files to change to appropriate GUI object.
>
> Also many cases, systematic use or default for bold or color is important to have nice look and feel. if it has css like another file shared among several layout files, we can achieve this easily. Definitely BXML can introduce such idea also(we may calll it BCSS).
>
> More concretely, CSS like pattern matching and some grouping by name('class' in CSS, but confusing in programming language), identification with id can be used here as well as the structure based pattern if we map the structure in XML(but may not be so important).
>
> For instance if some <bxml:ref =abc /> is mapped to list from checkbox, it can overwrite the mapping by:
> abc => checkbox
> groupA => checkbox
>
> Most of case, these mapping will be done based on associated data type, but it cab be overridden by BCSS file.
>
> Basically, this will achieve the goal to eliminate data related information from layout, and layout related information from application logic(Java).
>
>
> I agree fully with the concept of separating code and GUI, and there are several approaches for that. Martin Fowler made a series of articles covering pros and cons of such approaches: some designs are better suited to low level machinery (control design), others are better for higher level GUI design, with one or the other allowing better testing (replacing with mock objects), and so on.
>
> I wonder if Visage could be used for designing GUIs for Pivot. I haven't looked at its design recently, if it needs a library bigger than Pivot, it might not be worth the effort... ;-)
>
>
> --
> Philippe Lhoste
> -- (near) Paris -- France
> -- http://Phi.Lho.free.fr
> -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
>
>
> --
> Cheers,
> calathus
>
>
>
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by calathus <ca...@gmail.com>.
On Sat, Jan 29, 2011 at 1:44 AM, Philippe Lhoste <Ph...@gmx.net> wrote:
> On 29/01/2011 10:26, calathus wrote:
>
>> When we write GUI application in Java, the most important part is GUI
>> application logic (description of user interaction), not layout.
>> So we don't want to bother with layout in Java code level, also some GUI
>> object should be determined by the data type used in the application.
>> For instance, if type is boolean, we may want to map to check box etc.
>> And if we want to change these data type, we should not have to modify
>> the layout(most of case) file.
>>
>
> I agree with most, but not all. I think all GUI should be described in
> separate files, indeed, with no logic in it (or, at best/worst, only code
> pertaining to GUI logic).
> But the leafs must be part of this description: if the type is boolean, the
> GUI designer can choose to implement it with radio buttons, combo box or
> even a list, if they need/want it. It is not a concern of the code.
>
I think some missing ingredient here was the systematic default
specification mechanism like CSS in HTML.
If we start modifying layout for customized GUI object, the layout files are
going to depend on data type.
for instance, if the GUI object is specified as check box, and later the
data type is changed to String or enumerated type, such GUI object is no
longer appropriate. Or we may need to go through all layout files to change
to appropriate GUI object.
Also many cases, systematic use or default for bold or color is important to
have nice look and feel. if it has css like another file shared among
several layout files, we can achieve this easily. Definitely BXML can
introduce such idea also(we may calll it BCSS).
More concretely, CSS like pattern matching and some grouping by name('class'
in CSS, but confusing in programming language), identification with id can
be used here as well as the structure based pattern if we map the structure
in XML(but may not be so important).
For instance if some <bxml:ref =abc /> is mapped to list from checkbox, it
can overwrite the mapping by:
abc => checkbox
groupA => checkbox
Most of case, these mapping will be done based on associated data type, but
it cab be overridden by BCSS file.
Basically, this will achieve the goal to eliminate data related information
from layout, and layout related information from application logic(Java).
>
> I agree fully with the concept of separating code and GUI, and there are
> several approaches for that. Martin Fowler made a series of articles
> covering pros and cons of such approaches: some designs are better suited to
> low level machinery (control design), others are better for higher level GUI
> design, with one or the other allowing better testing (replacing with mock
> objects), and so on.
>
> I wonder if Visage could be used for designing GUIs for Pivot. I haven't
> looked at its design recently, if it needs a library bigger than Pivot, it
> might not be worth the effort... ;-)
>
>
> --
> Philippe Lhoste
> -- (near) Paris -- France
> -- http://Phi.Lho.free.fr
> -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
--
Cheers,
calathus
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
>> Pivot promotes separation of data and presentation via the MVC
>> pattern. However, you can't separate logic from presentation, or your
>> UI wouldn't do anything. :-)
>
> Well, I have seen everything, from a giant class building the GUI, getting and updating the data and handling the events, to more or less decoupled code.
> By "separating code and GUI", I was thinking decoupling business code (get from database, put in objects, transform it, put in database or other repository) and UI code (if user selects this radio-button, activate this list; when all mandatory fields are filled, activate the OK button).
> The frontier isn't always well defined (what are "mandatory fields"?) but one of the base, good ideas is to have most of the code to work without "real" GUI at all: ie. in a unit test, one can replace it with mock objects and get the code to work. (I have yet to test this idea...)
>
> This is a bit theoretical, mostly good ideas I saw, not applying particularly to Pivot or some other GUI framework. And unless the framework lacks flexibility, implementing this is more a question of discipline ("you can add code to GUI definition, but don't do that, except in well defined cases") than of framework.
That makes sense. Keeping subsystems decoupled so that their implementations can vary independently is almost always a good idea.
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 29/01/2011 14:25, Greg Brown wrote:
>> I agree fully with the concept of separating code and GUI
>
> I've said this before but I'll repeat it now: there is a difference
> between "separating data and presentation" and "separating logic and
> presentation". In HTML, the former is quite relevant since the
> presentation medium is a document. Combining formatting and semantic
> information in the same document can render your code unmanageable.
>
> Pivot promotes separation of data and presentation via the MVC
> pattern. However, you can't separate logic from presentation, or your
> UI wouldn't do anything. :-)
Well, I have seen everything, from a giant class building the GUI,
getting and updating the data and handling the events, to more or less
decoupled code.
By "separating code and GUI", I was thinking decoupling business code
(get from database, put in objects, transform it, put in database or
other repository) and UI code (if user selects this radio-button,
activate this list; when all mandatory fields are filled, activate the
OK button).
The frontier isn't always well defined (what are "mandatory fields"?)
but one of the base, good ideas is to have most of the code to work
without "real" GUI at all: ie. in a unit test, one can replace it with
mock objects and get the code to work. (I have yet to test this idea...)
This is a bit theoretical, mostly good ideas I saw, not applying
particularly to Pivot or some other GUI framework. And unless the
framework lacks flexibility, implementing this is more a question of
discipline ("you can add code to GUI definition, but don't do that,
except in well defined cases") than of framework.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
> I agree fully with the concept of separating code and GUI
I've said this before but I'll repeat it now: there is a difference between "separating data and presentation" and "separating logic and presentation". In HTML, the former is quite relevant since the presentation medium is a document. Combining formatting and semantic information in the same document can render your code unmanageable.
Pivot promotes separation of data and presentation via the MVC pattern. However, you can't separate logic from presentation, or your UI wouldn't do anything. :-)
G
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 29/01/2011 10:26, calathus wrote:
> When we write GUI application in Java, the most important part is GUI
> application logic (description of user interaction), not layout.
> So we don't want to bother with layout in Java code level, also some GUI
> object should be determined by the data type used in the application.
> For instance, if type is boolean, we may want to map to check box etc.
> And if we want to change these data type, we should not have to modify
> the layout(most of case) file.
I agree with most, but not all. I think all GUI should be described in
separate files, indeed, with no logic in it (or, at best/worst, only
code pertaining to GUI logic).
But the leafs must be part of this description: if the type is boolean,
the GUI designer can choose to implement it with radio buttons, combo
box or even a list, if they need/want it. It is not a concern of the code.
I agree fully with the concept of separating code and GUI, and there are
several approaches for that. Martin Fowler made a series of articles
covering pros and cons of such approaches: some designs are better
suited to low level machinery (control design), others are better for
higher level GUI design, with one or the other allowing better testing
(replacing with mock objects), and so on.
I wonder if Visage could be used for designing GUIs for Pivot. I haven't
looked at its design recently, if it needs a library bigger than Pivot,
it might not be worth the effort... ;-)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by calathus <ca...@gmail.com>.
This kind of requirement may be better understood from Java based Pivot
programing(that is what I'm doing).
When we write GUI application in Java, the most important part is GUI
application logic (description of user interaction), not layout.
So we don't want to bother with layout in Java code level, also some GUI
object should be determined by the data type used in the application. For
instance, if type is boolean, we may want to map to check box etc. And if we
want to change these data type, we should not have to modify the layout(most
of case) file.
But if these information is defined in BXML files, it creates dependency
between Java code and BXML file.
Essentially we may consider this as 'separation of concern' in AOP sense.
In particular, when implementing CRUD library with Pivot, if we write
separate BXML files for each entity class(for form pane and table pane
respectively), when the bean data type is changed, we must change all BXML
files. That is quite painful. if layout info and programming logic are
cleanly separated, this will not be necessary.
there are a few annoyance for BXML.
1) There are no default layout setting value mechanism.
2) some basic table pane (such creating two columns, three etc, are going to
be quite messy Java code(even BXML, it will be the same) Hard to understand
the layout from Program.
3) often if we remove terminal GUI object info from BXML(replace by
bxml:ref), the layout description will be much shorter.(if we introduce
special syntax for layout, it will be very short)
4) Actually one request(or supported?) is the ability to assign attribute
for a referenced object.(e.g, <bxml:ref id=abc width="20" ...> so that these
layout information can be set for the objects created outside of BXML.
The idea to make application logic independent from specific GUI library is
something I consider interesting but not so urgent. But if we only need to
use basic GUI component, and working in higher level API, it may be possible
to deploy same GUI application on different mode like desktop, browser,
eclipse...
The idea is somehow similar to the idea of ORM tools(like JPA).
On Fri, Jan 28, 2011 at 3:53 PM, Greg Brown <gk...@verizon.net> wrote:
> > Whether it is component or not are not matter here like block is
> expression or not. In other word it matters whether it is terminal element
> or not.
>
> Why? The whole point of BXML is constructing a hierarchy, and hierarchies
> generally consist of both leaves and branches. I can't imagine what benefit
> excluding the leaves would offer.
>
>
--
Cheers,
calathus
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
> Whether it is component or not are not matter here like block is expression or not. In other word it matters whether it is terminal element or not.
Why? The whole point of BXML is constructing a hierarchy, and hierarchies generally consist of both leaves and branches. I can't imagine what benefit excluding the leaves would offer.
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by calathus <ca...@gmail.com>.
On Fri, Jan 28, 2011 at 3:30 PM, Greg Brown <gk...@verizon.net> wrote:
> > I think using BXML like layout language separated from programming
> language would make sense.
> > But the current BXML is almost full programming language like JSP.
>
> That is not correct. BXML is primarily for UI construction. Scripting is
> optional (and unrelated to the actual markup).
>
> > From my experience using Pivot one month, I feel it would be better to
> have more concise layout language than BXML, which is dedicated to only for
> layout information. For instance boxpane/tab/split pane etc are layuout
> object. on the other hand, radio button/TextInoput etc are information
> receptor which should be part of Programming language (Java/Scala).
>
> BoxPane etc. are used for layout but they are also Components (like
> RadioButton, etc.). Further, they are all beans, which makes them valid
> elements for use in BXML.
>
Whether it is component or not are not matter here like block is expression
or not. In other word it matters whether it is terminal element or not.
These TextInput class etc are sort of terminal element. And often they are
associated with some data used from programming language. And from
programming point of view, what kind of GUI representation are used is not
important. Just we need to get/set data. So if these GUI class class
implements such API, it is much easier to access the data. right now if we
map some data to some GUI element, we need to cast concrete GUI class, and
getText and convert data each time. Another way to achieve this is to use
some adaptor which implement this API in order to wrap these GUI 'terminal'
instance.
>
> > And from programming point of view, the GUI aspect should be hidden from
> API level. That means they should just look like some String to some type
> converter. It should be associated with these type information, and provide
> some getter/setter to access user input data.
>
> That sounds really abstract (i.e. difficult to use and understand).
>
>
> G
>
>
>
>
--
Cheers,
calathus
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
> I think using BXML like layout language separated from programming language would make sense.
> But the current BXML is almost full programming language like JSP.
That is not correct. BXML is primarily for UI construction. Scripting is optional (and unrelated to the actual markup).
> From my experience using Pivot one month, I feel it would be better to have more concise layout language than BXML, which is dedicated to only for layout information. For instance boxpane/tab/split pane etc are layuout object. on the other hand, radio button/TextInoput etc are information receptor which should be part of Programming language (Java/Scala).
BoxPane etc. are used for layout but they are also Components (like RadioButton, etc.). Further, they are all beans, which makes them valid elements for use in BXML.
> And from programming point of view, the GUI aspect should be hidden from API level. That means they should just look like some String to some type converter. It should be associated with these type information, and provide some getter/setter to access user input data.
That sounds really abstract (i.e. difficult to use and understand).
G
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by calathus <ca...@gmail.com>.
Hi,
I think using BXML like layout language separated from programming language
would make sense.
But the current BXML is almost full programming language like JSP.
Many sample code in Pivot looks suggesting such approach.
These are misleading thing for the need of some layout language.
Even we have a simple GUI description In Scala/Java, these are compiled
langauge. So it is not possible to change them without recompilation.
>From my experience using Pivot one month, I feel it would be better to have
more concise layout language than BXML, which is dedicated to only for
layout information. For instance boxpane/tab/split pane etc are layuout
object. on the other hand, radio button/TextInoput etc are information
receptor which should be part of Programming language (Java/Scala). And from
programming point of view, the GUI aspect should be hidden from API level.
That means they should just look like some String to some type converter. It
should be associated with these type information, and provide some
getter/setter to access user input data.
Also this may allow to have higher layer API to remove specific GUI library
dependency.(maybe it might be possible to support both GWT/Pivot/SWT etc,
with common layout script plus receptor adaptor API)
Anyway this might have been a bit digression. But I would like to know other
poeple's option for this type of approach..
On Thu, Jan 27, 2011 at 10:36 PM, Philippe Lhoste <Ph...@gmx.net> wrote:
> On 27/01/2011 23:15, Sandro Martini wrote:
>
>> Just a quick info, me and Greg (and maybe other Pivot developers) are
>> very interested in Scala ... but as you the problem is to find enough
>> time :-) ...
>>
>
> Sure! I have the secret (well, not so much now) hope to help a little bit
> here.
>
>
> This week I committed some simple eclipse projects on Scala 2.8.x and
>> Pivot-2, in our Pivot-Scala project (
>> http://code.google.com/p/pivot-scala/ ), there aren't released
>> distribution files, but from its Subversion trunk you can download
>> everything even as a guest (you can find all the info under its Source
>> link.
>> But attention, it's a work-in-progress, and it's only at the beginning.
>>
>
> Like my own work...
> I also noticed the recent thread on Scala, I also share the feeling that a
> Scala DSL to replace BXML would be nice.
> But my initial work is to stick to closely to the current tutorial way (I
> would have put the list of states in a text file...) while using some Scala
> mechanisms. I like the line:
> states filter(_.toUpperCase.startsWith(text)) foreach(suggestions.add)
> replacing 5 lines of Java while remaining reasonably readable.
>
> Note: it is unfortunate that Pivot uses its own set of collections, it
> cannot interact nicely with Scala, unless re-doing some wrappers/implicits.
>
>
> Much more content could go there, for some I have already some working
>> test, and probably even Greg ... but I know Scala only a little so
>> anything is really much more time consuming.
>>
>
> Same here (Scala newbie, little time...).
> Trying to advance a bit by myself, for self-educational purpose, before
> looking at the work of others...
>
>
> --
> Philippe Lhoste
> -- (near) Paris -- France
> -- http://Phi.Lho.free.fr
> -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
--
Cheers,
calathus
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 27/01/2011 23:15, Sandro Martini wrote:
> Just a quick info, me and Greg (and maybe other Pivot developers) are
> very interested in Scala ... but as you the problem is to find enough
> time :-) ...
Sure! I have the secret (well, not so much now) hope to help a little
bit here.
> This week I committed some simple eclipse projects on Scala 2.8.x and
> Pivot-2, in our Pivot-Scala project (
> http://code.google.com/p/pivot-scala/ ), there aren't released
> distribution files, but from its Subversion trunk you can download
> everything even as a guest (you can find all the info under its Source
> link.
> But attention, it's a work-in-progress, and it's only at the beginning.
Like my own work...
I also noticed the recent thread on Scala, I also share the feeling that
a Scala DSL to replace BXML would be nice.
But my initial work is to stick to closely to the current tutorial way
(I would have put the list of states in a text file...) while using some
Scala mechanisms. I like the line:
states filter(_.toUpperCase.startsWith(text)) foreach(suggestions.add)
replacing 5 lines of Java while remaining reasonably readable.
Note: it is unfortunate that Pivot uses its own set of collections, it
cannot interact nicely with Scala, unless re-doing some wrappers/implicits.
> Much more content could go there, for some I have already some working
> test, and probably even Greg ... but I know Scala only a little so
> anything is really much more time consuming.
Same here (Scala newbie, little time...).
Trying to advance a bit by myself, for self-educational purpose, before
looking at the work of others...
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Sandro Martini <sa...@gmail.com>.
Hi Philippe,
congratulations for your sample projects, as soon as possible I'll try
to look at them.
Just a quick info, me and Greg (and maybe other Pivot developers) are
very interested in Scala ... but as you the problem is to find enough
time :-) ...
This week I committed some simple eclipse projects on Scala 2.8.x and
Pivot-2, in our Pivot-Scala project (
http://code.google.com/p/pivot-scala/ ), there aren't released
distribution files, but from its Subversion trunk you can download
everything even as a guest (you can find all the info under its Source
link.
But attention, it's a work-in-progress, and it's only at the beginning.
At the moment the content is minimal, but you can find:
- pivot2-dependencies, containing all Pivot jars with all classpath set
- pivot-scala-common-scala, some common code for Pivot and Scala interaction
- scala-use-pivot2, standard eclipse project with some minimal Scala
samples, like HelloWorld, HelloBXML, and others to come ... Binding
samples, etc
- pivot-scala-test-maven, the same of scala-use-pivot2, but using
Maven (so all other eclipse projects in the same workspace are not
needed)
-- this could be a starting point for a pivot-scala-archetype for
maven, I'm slowly working on a Java version, and after on this ...
Much more content could go there, for some I have already some working
test, and probably even Greg ... but I know Scala only a little so
anything is really much more time consuming.
For comments, suggestions, etc we are here :-) ... thank you at the moment.
I hope to discuss with you (and others) on how we can improve this.
Bye,
Sandro
Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Posted by Greg Brown <gk...@verizon.net>.
> Yes, I am re-reading Douglas Adams' works...
Excellent. I have read them several times myself.
> I am back!
Welcome back! :-)
> http://bazaar.launchpad.net/~philho/+junk/Scala/files/head:/PivotTutorials/
> Note: I have put neither the Apache license nor mine (a simple zlib/libpng one) as header of the files, not sure what is appropriate. I made my own package, to make clear this is not done by Apache.
How you license (or not) your own code is up to you. If you modify/redistribute any of the Pivot source code, you'll need to retain the ASL header.
> Basically, I run the org.apache.pivot.wtk.ScriptApplication class with the parameter -src=path/to/text/text_inputs.bxml with the classpath set to the runtime classpath (the same used to run the pure class files) and the resource files (BXML and others) copied at the same place.
>
> But the ScriptApplication fails to find the BXML file.
...
> With an absolute path, I get an error like:
...
Try using a path on the classpath, not a file system path. For example, --src=/com/foo/bar/my_file.bxml.
OTOH, you may want to simply implement the Application interface yourself rather than using ScriptApplication. For what you are trying to do, I think it might be a better approach anyways.
> Oh, on an unrelated note: in the past, I had no problems to run Pivot demos (on XP), it loaded fast and was displayed nicely.
> I wanted to follow the tutorial online, and the Sample Application demo shown the Java wait logo for quite some time (several minutes, I would say), then a black area where the applet should be. Nothing in the Java Console, and actually it closed as if the applet crashed.
Could be a JVM issue. Might also be related to the use of a volatile image for buffering. Try setting -Dorg.apache.pivot.wtk.disablevolatilebuffer=false when you start your app.
> Mmm, tried again while writing this mail. First got a black applet, then the app. Again, got a black applet only. Again, works fine!
> Trying Color Scheme Builder, it works OK after accepting the security warning (mmm, I can't type values in the spinners? Annoying, it is slow to go to a value).
Spinners are not currently editable, though there is a JIRA ticket for this.
Stepping through the values reloads the entire sample UI, so it can be slow.
G