Thanks very much for the reply Christian (and the clarification on the use of UIfilters - I'm sure I would have scratched my head for a while on that one ;) )
As I gain a higher degree of comfort with the Riena framework, I'd be happy to contribute back in any areas that are deemed mutually beneficial.
One thing that I'm wondering right now - we've got a number of editors that we've built to support some of our proprietary file formats (they're really more viewers, since they're read-only, but they're based on the eclipse FormEditor for multi-page display. eg - for our EEPROM image file format, one page shows a visual representation of an EEPROM layout, the other page shows the absolute data.) Right now I'm not sure how this would fit into the Riena framework, as all of the SubModuleViews extend ViewPart and there doesn't seem to be support for EditorParts.
Any suggestions as to how I might be able to open a FormEditor in Riena? Ultimately, I kind of envisioned having a 'files' modulegroup node in the side navigation view that contained a list of available resources (EEPROM image files, assembly programs etc). Selecting a file/submodule would open the appropriate editor (just as views are handled currently).
Thanks
Todd
-----Original Message-----
From:
riena-dev-bounces@xxxxxxxxxxx on behalf of Christian Campo
Sent: Wed 4/29/2009 12:31 AM
To: Riena Developers list
Subject: Re: use case introduction (was RE: [riena-dev] wizards in riena?)
Hi Todd,
Am 28.04.2009 um 21:58 schrieb Todd Lee:
Thanks Christian,
So after alot of reading ;) it seems to me that Riena is pretty much
in the sweet spot of what I'm looking for. Granted, my application
only scratches the surface of Riena's capabilities (standalone
client only right now, nothing on the remote/server side).
good to hear the part with the "sweet spot". no problem if its just a
client. we have projects too where the customer justs wants the client.
As I mentioned earlier, my company ships an IDE based 'Engineering
Development Kit' for use by developers of applications for digital
signal processors (we make the chips).
The requirement has come up for something of a 'lite' kit for use by
non-technical users who simply have a device on their desk and need
to connect to it (using a variety of proprietary/off the shelf
communications hardware/protocols) and download applications/EEPROM
images onto it etc...
As far as tool support that would be useful for us, the following is
based on my design thus far:
1) dockable/detached view support
- picture a 'common navigator' based view that shows applicable file
resources which can be dragged and dropped on my main sub-
application view showing currently connected devices (actionHandler
kicks off download to device)
- also optional console window that shows output of download process
so detached view support is for you :-)
The prototyping that Elias has done looks really promising. I'm
imagining a console view that can be opened below the active
subapplication and perhaps a resource window that can be opened beside
2) simple wizard support
- one of our requirements is 'wizard' like support to help our
customers connect their devices. This generally involves stepwise
selection of appropriate device, communication protocol/interface
settings and saving the configuration. I suppose that in the absence
of traditional wizards this could still be accomplished using a form
view with progressive UI filters (looking at the playground in the
example client) that proceed with the stepwise enablement of
controls as selections are made/info is input.
one important point about UI filter, a limitation if you want, is that
ADDING a UIFilter HAS TO ADD a RESTRICTION. You can add and activate
many UIFilters and take them away in any order. So want you want can
be done but just to be clear about how you do it. You can not add a
UIfilter to enable a field. You can however remove a UIFilter that
disabled a field.
This was however necessary given the current marker infrastructur that
we have. Likewise a UI Filter can hide fields, views, menu items etc.
or add validation rules. No filter can be defined to make things
visible.
Just a different way of thinking and no general hurdle to implement
anything that you are sketching out.
3) interaction with external applications
- we use launch configurations right now to kickoff utility apps
used to download programs to a device etc. If there was an easier
way to do this in riena, it would save a lot of dependencies on the
existing eclipse core/debug framework
we didnt have yet the requirement. We can always discuss that, add a
bug and talk about how to implement that, maybe you even like to
contribute a generic functionality to Riena.
4) easy command line application execution with arguments
- Ideally, I'd like to be able to fire up my exported product using
a basic shell extension (ie - right click on an EEPROM image file
and select 'Open With > My Fancy Riena Application') The
SwtApplication can start a specific subapplication based on the file
argument passed.
That should be possible either with what we have or some additions.
That's pretty much it, and I realize some of it is probably out of
the scope of the Riena project (but you asked ;) so you got my
wishlist) - everything else, you've already provided, with the
simplified/customizable UI and easy navigation. Thanks again,
looking forward to digging a little deeper!
I really rather like to focus on how to do it than if we do because it
might be out of scope. If you like to use Riena and there is a bit
missing to accomplish that, this would in general mean that its in
scope especially if these are UI "thingys". We dont write device
drivers for EEPROMS (that is out of scope) but you dont expect us to.
There is always a chance that we might implement something NOT "next
week" after you enter it in Bugzilla if its something that we dont
need and we are short in ressources. But contributing by you (after a
lively discussion how to do it) should always work.
Cheers,
Todd
cheers
christian
-----Original Message-----
From: riena-dev-bounces@xxxxxxxxxxx on behalf of Christian Campo
Sent: Tue 4/28/2009 12:04 PM
To: Riena Developers list
Subject: Re: [riena-dev] wizards in riena?
Hi Todd,
no question is naive (to start with), it just points to a topic that
is not enough explained :-)
The simple answer would be to say "look at the Riena proposal, No tool
support" http://www.eclipse.org/proposals/riena :-)
We have however implemented a little wizard once which is currently
not so well maintained that enables you to create Riena apps. However
the use is limited because you can basically generate a sample
application in your own namespace with your own packages but still it
will be the same as the samples that you can already see in the target
platform as samples.
If you want the way to go is to request an enhancement and file a bug
report. :-)
You can also start with telling us what kind of applications you are
building and what kind of tool support would be helpful.....
christian
Am 28.04.2009 um 20:14 schrieb Todd Lee:
Hi there,
As I work through my investigation of riena for use in our product,
I've noticed that there doesn't seem to be anything analogous to the
notion of the Wizard/WizardPage in vanilla eclipse. Is there a plan
for wizard support (ie Wizard/WizardPage Rigets like you seem to
have for some other dialog based elements) or is the intent that the
lnf be applied to the standard wizard/wizardpages directly without
the need for the riget interface? (I seem to recall reading
somewhere that setting a system property could apply the riena lnf
globally...?)
My apologies if this question ends up being naive, I'm definitely
learning as I go...
Thanks, Todd
<ATT00001.c>
<ATT00001.c>
<ATT00001.c>